昨天烧晚饭的时候，我注意到包装盒上的烹饪说明里有个很有意思的事情：三种烹饪方法的第一步是一模一样的，都是 “If frozen, defrost in refrigerator overnight”：

同样的内容重复了三遍，这在不少程序员的眼里是很糟糕的写法。遇到这种重复的内容，而且已经满足了Rule of Three，他们一定会要把它提取出来，放到一个公共的地方。如果让他们来重构这个烹饪说明，他们会增加一个公共的 “准备工作” 模块，把 “If frozen, defrost in refrigerator overnight” 这句话放到 “准备工作” 里：

他们这么做的理由是：

1. 这个烹饪说明显得更简洁了
2. 这个烹饪说明更容易维护，下次如果要修改 “If frozen, defrost in refrigerator overnight”这句话，比如把它改成 “If frozen, defrost in refrigerator for 12 hours or more”，就只需要修改1个地方，而不是3个地方。

在程序员的世界里，当一个人提出不要 copy/paste 代码时，几乎是不会遇到什么反对的。但是，减少重复的代码并不是一条“第一性原理”，它并不是不言而喻、不证自明的。减少重复的代码只是一种手段，它的目的是减少问题、减少工作量。如果在多个地方重复同一段代码反而可以减少问题、减少短期和长期的工作量，那就应该让它去重复，不要去抽取出来。

重复有重复的好处。我在蚂蚁的时候，经常给周围的人转发一篇题为《Write code that is easy to delete》的文章。这篇文章有一个核心观点：增加重复可以减少依赖。减少依赖可以降低风险和减少工作量。如果我的代码在另外N个地方被引用了，下次我修改我的代码的时候就不得不加倍小心、三思而行，生怕我的改动导致别人的代码无法正常工作。

对于重复，我的观点是：如果有两个地方有同一段逻辑，或者同一段文本，我们不应该简单粗暴的直接挥舞 Don’t Repeat Yourself 的大棒。我们要问清楚：这几个地方是否必须要保持一致的？如果要，那么怎么确保它们是一致的？如果不一致了会有什么后果？我是不主张在团队里大张旗鼓的提倡 “以代码复用为荣，以copy/paste为耻“的。

如今听说过“惠普之道”的人，估计都是至少四十岁以上的了。我刚毕业那几年，大家都在说“惠普之道”。《惠普之道》是一本九十年代的书，英文书名叫”The HP Way“（我估计 “Aliway” 也是从 “The HP Way” 来的）。那时候惠普在大家眼里是一个成功的公司，Carly Fiorina是那时候最火的CEO，江湖地位堪比今天的Elon Musk。

二十年过去了，现在很少听到有人讲“惠普之道”了，我甚至怀疑如今刚毕业的大学生可能连惠普这个公司都没听到过。现在大家都在学谷歌，因为谷歌是一家成功的公司。其实，谷歌成功已经有很多年了，只不过出圈需要一个过程。以前谷歌还只在圈内红火的时候，大家已经在学了，大家都在说 20% time 怎么怎么好，怎么怎么培育创新。

这两年好像不太听到有人讲 20% time 了，这几年大家都在学谷歌的 OKR。满眼都是各种文章阐述 OKR 的精髓是什么、OKR 和 KPI 的本质差别是什么、为什么 OKR 比 KPI 好。甚至连有些政府部门都在搞 OKR。虽然有很多人 clarify 说我们搞 OKR 并不是跟风、并不是因为谷歌搞了 OKR 所以我们也要搞，但夜深人静的时候扪心自问，如果谷歌没有那么成功，OKR 还会有那么多人学吗。

这样的例子还有很多。二三十年前，通用电气如日中天的时候，大家都学通用电气的末位淘汰，感觉末位淘汰是保持大公司企业活力的关键。后来通用电气走下坡路了，大家就开始反思，反思末位淘汰是不是导致微软的企业文化问题的原因，一家接着一家的公司都把末位淘汰和 curve 给取消掉了。

谷歌之后最红的科技公司是 Facebook。Facebook 声名鹊起的那段时间，大家都学 Facebook 搞 Hackathon ，但这两年大家讲 Hackathon 渐渐讲的少了。真正被 Facebook 带红的是 Monorepo（大库）。或者说，Monorepo 是被谷歌和脸书两家一起带红的：谷歌和脸书都是用大库的，那肯定不是巧合吧，而且谷歌和脸书的研发效能的口碑都是顶流的，让人不得不相信大库一定在里面起到了很大的作用。

大库其实也有大库的痛苦。上周我做了一个 diff，把六十几个 Dockerfile 里面 pip install 的 “-vv” 参数给去掉了（that’s a story for another day）。这个 diff 到现在还在等 code review，因为这个 diff 动了十几个微服务的 Dockerfile，要那十几个团队的人都 code review 通过了才能 land。除非我一个个 team 一遍遍的催，否则估计这个 diff 永远没法合并了。

大家都说大库的好处是做这种大面积 horizontal 的改动比较容易。我看也不见得有多容易。看样子，到头来我可能还是会把这个大 diff 拆成十几个小 diff，每个微服务一个 diff，单独做 code review。但这样搞一堆小 diff，那和每个微服务单独一个 repo 有啥差别呢。

早上填了一个公司内部的 developer productivity 满意度调查。这种调查在我以前公司也经常搞，我相信其他公司也有。今天这个调查我基本上每一项填的都是 Very Satisfied 或者 Satisfied。其实现在每天都能遇到各种问题，各种不完善的地方。但我也没觉得不满意，因为这样那样的问题、这样那样的不完善的地方都很正常，在中美两国的各个大厂小厂都普遍存在。就算是几家整体上做的很好的公司，到具体的团队也一样有很多问题。有问题就一点点搞呗。

满意度、幸福感，很大程度上是基于期望的。我上周四买了两顶帽子一件衣服，这周一收到邮件，说我的 order 已经 shipped 了。看了看 UPS tracking，要这周五（明天）deliver。这水平比淘宝差到不知道哪里去了。不过我也没有觉得啥不满意，因为期望低呗，我反正也不急着用。而且我知道美国这些网站的尿性，所以买东西都是 plan ahead 的。

如果有个满意度调查，问我对美国 online shopping 的 shipping speed 满意不满意，我大概也还是会填 satisfied。所以满意不满意和真的做的好不好之间没有太直接的联系。满意不满意和被调查的这个人有没有见过世面也没关系。过去几年我是已经习惯了淘宝和京东的速度的。京东上买个洗衣机都能隔天就送到，美国你买个洗衣机试试看。

“研发满意度调查” 或者 “研发幸福感调查” 的结果，看看就好。如果今年的结果比去年的满意度高、幸福感高，也别太当回事儿。这个结果可以拿去给不称职的 CTO 看，可以拿去给做业务出身的总裁们看。真的拿着各个团队的 “研发满意度” 做横向排名的，非蠢即坏。其实很多老板们心里也明白这个道理，很多时候大家都只是看破不说破罢了。

满意度高不代表 developer productivity 做的好。做的好的团队和公司，满意度和 “研发幸福感” 调查的结果完全有可能比做的不好的还差。全球 happiest countries 榜上名列前矛的很多国家同时也在 depression rate 榜上名列前矛。还有个说法说不丹是世界上 happiest country，但不丹人民的生活水平可比不了那些发达国家。所以“研发幸福感”这东西，还有那些员工满意度调查，只能 take with a grain of salt。

以前在微软的时候，每年都有一个员工满意度调查，叫做 MS Poll。那里面有一部分问题是关于你对你的直属老板的满意度。之前阿里巴巴没有这个，我就跟我们的大G和BP建议说要搞一个，所以后来阿里巴巴就搞了（这个因果关系就类似于公鸡打鸣了所以太阳就出来了），叫做 “管理者快照“。这东西挺好的，让大家对自己老板的不满有地方可以输出，这个分数也让各级老板有所忌惮。

以前在微软的时候，各级主管对这个满意度调查还是满上心的。分数如果很难看，日子多少会有点儿不那么好过。每年有这个分数在，我们做主管的一年到头都要很小心，团队要好生伺候着，就怕到时候分数不好看。临近年度调查的时候还要多搞一些聚餐，拉拢拉拢感情，各种暗示。但有时候，辛辛苦苦一整年，调查前一个月来了个紧急项目加班很多，一年的努力就白费了。

怎么让 MS Poll 分数高一点，这事情困扰了我很多年。直到有一次，我当时的老板给我说了他的一个秘诀。每次临近调查的时候，他都会找他的手下做 1:1，聊的时候就会把 MS Poll 里面的那几个问题先问一遍。人嘛，当面都是不太好意思说太难听的，所以 1:1 的时候被问到了都会说”还不错“、”挺好的“。神奇的地方在于：等到过几天填正式的调查表的时候，你选择的答案会不由自主的向在 1:1 时候自己嘴巴里说过的话靠拢，会更偏向于选择”满意“、”比较满意“。

我当时听他讲完后的感觉就是：哇塞，还能有这样的骚操作啊。YYDS！

有一次在我们项目的Slack频道里，在一件大家争议很大的事情上，我发现我的思路和我老板的思路出奇的一致。我当时犹豫了一下，要不要在我老板的那句话下面加个点赞。我犹豫下来的决定是：我没有点赞。

以前有一次，我是老板。也是一件大家意见很不一致的事情。那次，我下面有几个人就公开站我，结果他们被其他人炮轰，说他们是拍老板马屁。我也连带的被喷了，说我就是古代的昏君，让自己 surrounded by 佞臣。所以我后来明白了，为什么老板都很少发表自己的观点。

拍老板马屁，在以前古代，叫佞臣。古代的官儿们很喜欢给其他官儿扣一顶“佞臣”的帽子。大家的风气是觉得跟皇帝对着干是刚直不阿，支持皇帝的想法是拍马屁、是佞臣。我觉得皇帝心里也很苦闷啊。大家都怕被扣佞臣的帽子，搞得懂自己、支持自己的想法的官儿都不敢说话，皇帝多孤独啊。下次遇到有大臣站自己，皇帝还要担心他们会不会被扣上佞臣的帽子。

大家这么防着佞臣，是要防止有人就是通过拍老板马屁来捞好处，要防止皇帝被马屁精包围了，这样皇帝就不能兼听了，皇帝就不能看到自己的不足。这不是最近大家都在批某大，说许某印就是被马屁精包围了。 

At the risk of being overly confident，我觉得我是能分辨清楚我手下谁是 yes-sayer、谁是真正的思路一致的人的。子曰，君子不以言举人。主要就是看行动，看他们做的事情。不过也有很多人会就盯着老板关心的事情做。这样的风气要是不刹住，就没人do the right things和那些看不见的脏活了。而且，从逻辑上来说，可能虽然我觉得我能分辨马屁精，但我实际上还是会被骗。就好像觉得自己不会被金融诈骗的人，还是会被金融诈骗。

但反过来想想，有时候，让自己的手下觉得自己很容易骗，其实不是件坏事。哈哈。

2021年诺贝尔经济学奖的获奖理由是“因为他们对因果关系分析的方法论贡献”。很多人觉得这个奖给的很水。我觉得一点都不水。因为归因太难了。

那几年，多少次半夜醒来（figuratively speaking），脑子里挥之不去的就是那些问题：你怎么证明这个结果是你做的这些事情的结果？你怎么证明你不做这个事情就没有这个结果了？今天有这个结果，原因很多，你做的这个事情在里面贡献了多少？你怎么量化你做的这个事情的效果？

代码覆盖率从80%提升到90%，效果是什么？节省了多少研发时间？人均每天代码行数因此提升了多少？提升了多少研发幸福感？迭代交付周期因此缩短了多少？需求吞吐量因此提升了多少？对业务增长的贡献是多少？千行代码缺陷率因此下降了多少？降低了多少个P1P2故障？服务可用率提升了多少？资损故障因此下降了多少？

CI通过率从90%提升到99%，效果是什么？节省了多少研发时间？人均每天代码行数因此提升了多少？提升了多少研发幸福感？迭代交付周期因此缩短了多少？需求吞吐量因此提升了多少？对业务增长的贡献是多少？千行代码缺陷率因此下降了多少？降低了多少个P1P2故障？服务可用率提升了多少？资损故障因此下降了多少？

主干开发，效果是什么？节省了多少研发时间？人均每天代码行数因此提升了多少？提升了多少研发幸福感？迭代交付周期因此缩短了多少？需求吞吐量因此提升了多少？对业务增长的贡献是多少？

做code review，效果是什么？对业务增长的贡献是多少？千行代码缺陷率因此下降了多少？降低了多少个P1P2故障？服务可用率提升了多少？资损故障因此下降了多少？

今年故障下降了70%，和你做的这些事情有多少关系？你怎么证明？为什么不是因为我们的工程师能力提升了？为什么不是因为我们做了很多架构治理？为什么不是因为今年立项抓得严了？为什么不是因为公司今年更加重视了？为什么不是因为今年比去年少了很多大型重构？

我们做事情都是要讲投入产出比的。你说的这些事情，都是对的。但是要看投入产出比，我们没有无限的资源。你没办法量化度量你这些事情的效果，你怎么衡量这些事情的投入产出比？

你证明不了你做的事情和结果的关系，那凭什么给你好的绩效？你做的事情和结果的关系，是你自己要证明的。你证明不了，那怪不了别人。你证明不了，就算拿到结果了，也是碰运气的，不是可以复制的结果。

所以我觉得2021年诺贝尔经济学奖一点都不水。每一个被“你怎么证明这个结果是因为你做的这个事情”这类问题反复折磨过的人都知道，归因非常难，非常难，非常难。

最近几天都在修case。其实不是我的case。都是其他那些team的。自己不看，总是怪infrastructure。那只好我自己来了。

好像中国和美国的程序员都是类似的：自己的用例失败了，总是不会先从自己身上找原因，总是先blame infrastructure。总是要别人一而再再而三的把铁一样的证据放在他们面前了，他们才会承认是自己的用例有问题。

承认了自己用例有问题还要继续找借口：哎呀，你们这个工具不好用啊，排查起来很辛苦；哎呀，你们这个工具不好用呀，我要单独跑一下用例很辛苦；哎呀，你们这个工具不好用呀，能不能把失败的用例给自动重跑一下呀;哎呀，你们这个工具不好用呀，能不能智能一点，做一下智能分类、智能诊断。就是不肯乖乖的把自己的case修修好。

要不说姜还是老的辣。今天修的这个case，那几个兄弟之前都挣扎过了，都挣扎不出。我从中午开始看的，看啊看，看啊看，都是从来没看过的代码。看到晚上，被我灵光一现看出来毛病了：有个地方把now()转成“US_EASTERN”时区的时间。当时就觉得这个地方很fishy。

Fishy 在字典里的意思是 arousing feelings of doubt or suspicion，翻成中文就是：这里看着很可疑，这个地方感觉怪怪的，这里感觉不太对劲。

这不有个故事吗。说有台机器坏了，谁都搞不定。最后请了个老师傅来。老师傅看了看，把一个螺丝拧紧了，机器就好了。老师傅收了1000块钱，人家嫌贵。老师傅说，拧一个螺丝只要10块，但剩下990块是知道拧哪个螺丝。

老程序员就是值这个钱。改一行代码看上去很简单，只值10块钱。但能看出来要改哪一行代码，就凭这个，老程序员的工资就比新兵蛋子高。

写这个“US_EASTERN”的估计也是一个新手，没吃过timezone的苦头的，顺手就写了。他这一顺手，后面好几个人好几天时间就没有了。要是再到线上出问题，或者等到屎山已经很高了再搞技改，那就是动辄几百人日的代价了。

“US_EASTERN”的问题就是：每天有一个小时的时间，当“US_EASTERN”还是10月19日的时候，真正的纽约当地时间已经是10月20日了。就差这一天。每天这一个小时里面这个case必败。大家之前看不出一个头绪，看不出什么pattern，原因之一也是之前败的并不频繁。这是不是从另一个侧面也说明，我司在西海岸的同学们到晚上九点提代码的人就不多了。

这两天还修了一个很有趣的case。有个case，偶尔会败。这个case其实没干啥，就是在本地的DynamoDB里面插好多条假user，然后再读出来，看看对不对。但有时候在PutItem的时候会报错，报“Cannot do operations on a non-existent table”。好几个人看了，看不明白，没头绪。

那天我看了一会儿，也没看出来为啥。但我就看到一个地方很fishy：这个用例，用一个for循环插数据，for循环循环了1000次。我看到那里的时候就眉头一皱：有必要吗？

我就去问这个用例的原作者。还好这个用例还算新，八月底加的，作者还在。作者说，其实1000就是随便放的一个数字，到底是 100还是1000，对这个用例来说并没所谓。我说，那要不我帮你改成100吧。因为这个case时间太长了，现在要跑八九秒钟。我改成100，估计不到1秒就跑完了。他说可。

于是我就路见不平的改了。把循环1000次改成了100次。然后我发现，改完以后，这个用例不flaky了，“Cannot do operations on a non-existent table”彻底消失了。敢情这背后的原因就是循环太多了哇，把本地DynamoDB给压坏了。

那个作者还算心思缜密，还问我，这是不是意味着在线上也会有性能问题。我说，也许吧。也许只是本地DynamoDB比较搓，云上的可能就没这个问题了。你要是实在不放心，去云上直接测一测。总之，就别在CI里面跑压测了。

用例不稳定，基本上每个公司都有这个问题。很多人都想走捷径，老是把“弯道超车”挂在嘴上，想搞个什么大招可以一下搞定，或者想另辟蹊径，绕开这个问题，或者搞个自动重跑什么的先对付着。其实，用例不稳定的问题，只有一条路：好好写代码。不稳定的用例好好分析，好好修，修了就修修好，不要东加一个sleep西加一个retry的糊弄过去。

这就和减肥是一样道理。不想改变不健康的饮食习惯，但还想减肥，那是不可能的。局部减脂，不存在的。代餐，都是智商税。减肥的办法，就是做正确但艰难的事。

昨天写了一篇design spec，关于code ownership的。文档上来就引用米尔顿·弗里德曼的话，在design spec里可以算是逼格非常高的了。

文档是从上周就开始写的，昨天写完的。写了足足有18页。我也很惊讶，居然写了那么多。本来以为四五页就差不多了。Code ownership这个事情说起来其实很简单，一句话就能讲清楚：加一个OWNERS文件。

咋就把一句话变成了18页了呢？这不是要”starting from first principles”嘛。国内互联网也有类似的说法，叫做“你的底层逻辑是什么”。这两年阿里被黑的厉害，其中就包括阿里的人用的那些互联网黑话，像什么“抓手“、”赋能“、”闭环“，还有“底层逻辑”也是。

其实黑话这个事情，东西方都一样。美国也有互联网黑话。比如，刚工作那几年，有一个词我每次听到都想吐：synergy。美国的黑话也在不断进化，这两年synergy听到的少了，有些新的黑话涌现出来，比如我回国前还很少听到有人讲first principles，这次回来后好像用的人多起来了。

因为要“starting from first principles”，所以把一句话就能讲完的事情写了18页。有段时间没写那么长的文档了。上一次是写了一份九十几页ppt的新财年规划。那也是被杠精逼的。不管你怎么写，他们总是能给你挑出点毛病来。

我谈目标，他说你这个没有落地过程。我谈要做什么，他说你没有推导过程。我谈why，他说你能不能告诉我们要做什么。我谈远大的目标，他说你太理想化。我谈具体目标，他说你留白不够。我谈重点， 他说你不全面。我谈全面了，他说你要抓重点，就讲top 3。我谈原则，他说你不要一刀切。我谈原理，他说你不要老是讲概念。我谈抓手，他说你这些是单点，没有体系化。我谈体系，他说你不要讲大道理。我谈最佳实践，他说那套东西在这里未必适用。

没办法，为了堵住杠精的嘴，只能都写上，于是就变成九十几页ppt了。可谁能想到，我把所有东西都谈了，他说你怎么ppt那么多页。

前几天看到鹿叔叔他们家的草坪。真心的漂亮。又绿又厚，而且草坪上有那种均匀整齐的一条条的纹路。我知道那是割草的时候割出来的，而且需要一定的手法，才能割出那样的纹路来。以前我们家住在Education Hill的时候，我也一直想在我们家前院的草坪上割出这种花纹来。但一直没有很成功。

Education Hill，中文可以翻译为“教育山”。Education Hill的那套房子是我第一次住有草坪的房子。刚搬进去的时候，草坪很一般。远远的瞟一眼觉得还可以，挺绿的。但经不起细看，只要走的近些，也不需要太近，只要是从我家门口的人行道上经过，就可能看到草坪上很多的杂草，还有很多秃了的patch。

那时候我立志要把这片草坪整好。而且要原地整，要起死回生。把整片草地铲掉重新铺，固然是能焕然一新的，但我必须要挑战更高难度。后来我做到了。我那时候很自豪我家门口的那片草皮是我们小区最好的。不，甚至可以说是整个教育山上最好的。

那时候朱逢霖老嫌弃我，说为啥要花那么多力气去除杂草呢，杂草也是绿的嘛，剪一剪剪平了，也是绿油油的一片呀。我觉得那就叫不可与夏虫语冰。别的不说，咱不能给中国人丢脸不是？Daphne在底特律给中国人丢的面子，咱要在教育山给挣回来。//tongue-in-cheek

后来搬家了，搬到现在住的这套房子。我现在就坐在后院写这些字，面前就是后院的草坪。这片草我已经基本不打理了，也没打算重新铺。费那劲儿干嘛呢。杂草也没关系，杂草也是绿的嘛，等草太长了的时候拿割草机推一下就可以了，剪平了就都是绿油油的一片。剪草其实也不是为了好看。草太长了，影响郑轶嘉练soccer，球滚不动。

倒也不是我现在对生活品质没追求了。就是觉得彩云易散琉璃脆。以前在教育山的时候草坪整的那么好，都舍不得让郑轶嘉踢球。有时候来个contractor来修个啥的，电线和管子从路边拉到房子里，直接从草皮上压过去，那个心疼啊。现在家里的草坪，怎么zao（第四声）都不心疼。

我的一些片面的看法：

原因1: 医疗保险不是充分市场化的。很多人会隔几年换一个car insurance的保险公司，以此来降低保费。长此以往，car insurance及其相关行业（配件、body shop、glass shop）竞争比较充分，价格也相对合理。医保的保费是公司付的，公司不会那么频繁的shop around。

原因2: 缺乏incentive。Car insurance的保费是自己付的，会在自己的银行账单上看到被扣掉的钱。医保的保费是公司付的，个人是看不见的。人性就是对看不见的东西就不那么care。

原因3: 还是缺乏incentive，对节省保费的行为没有激励。Car insurance对safe driver是有激励的，连续几年不出事故没有claim，保费会低；另一方面，如果出了事故有claim，保费会加。出于自私的想法，每个司机都有动力来安全驾驶。但health insurance并没有这样的激励机制，或者激励更加间接、反馈周期更长（可能长达几十年）。

原因4: 医疗保险的存在间接拉高了医疗费用。举个例子：以前微软员工的医疗保险里面每年可以报销$200的配眼镜费用。人的心理是：“既然我能报销200，那如果不用用足，那岂不是亏了”。结果，Redmond附近的眼镜店里面基本都是$200美元上下的镜框，便宜的镜框反而很少。

原因5: 医疗保险鼓励了浪费。还是拿前面的配眼镜来举例子。因为“不用就浪费了”，所以很多人就算不需要，也会每年去配眼镜，只是为了把那两百块钱花掉。我们的医保里面还有一些其他项目，比如可以报销$300用来买泵奶器，于是大家就有“不买就浪费了”。这些都鼓励了物资的浪费，也从而推高了保费。

原因6: Health insurance premium在美国是tax deductable的。也就是说，保费是政府补贴的（subsidized）的。通常来说，政府补贴会人为得推高价格。政府对医疗保险进行补贴也会推高医疗保险的价格。Btw，对health insurance premium的tax deduction是一种劫贫济富的做法：高收入的人和他们的雇主会买更贵的保险，而且高收入的人的effective tax rate更高。这个道理类似于mortgage interest的tax deduction也是一种劫贫济富。

原因7: 人和东西不一样，人不能换新的。车子撞坏了，如果修理费用太高，对明年保费影响太大，我可以选择不修，直接total掉，再买辆新的。这样其实有助于降低保费。但人不行，除非是真的走投无路了，人一般不会说这个手术太贵了，不做了，直接拉去埋了，重新再生一个。

至于怎么降低医保费用，Democrats说，看病太贵了，所以我们要让每个人都有医疗保险，我们要强制每个人都买医疗保险，因为所有人都买医疗保险了，医疗保险的保费才能降下来；Republicans说，看病贵，要从根子上找原因，要找出来为什么看病贵，要降低药品价格，要在医疗行业引入竞争，要让医疗费用更透明，用市场的手段让价格降下来，让大家都看得起病。在这个问题上，我认为Republicans的思路更正确一些。

—-

注：本篇写于2017年

我发现，Democrats和Republicans之间，除了大政府vs小政府、trickle-up vs trickle-down等差别之外，还有一个差别：解决社会问题是治标还是治本（这里对治标和治本并无褒贬）。在很多社会问题上，Democrats都是“治标”的，而Republicans都是“治本”的。例如：

枪支问题。

Democrats说，枪支问题那么严重，出了那么多的mass murder事件，所以我们要控枪，要严格管理枪支的买卖。有些Democrats甚至直接说taking your guns。而Republicans说，枪只是一种犯罪工具，控枪不解决根本问题，因为坏人总是有办法可以搞到枪，枪落在坏人、精神有问题的人手里才会出问题，所以解决问题的根本出路还是要解决贫穷问题、在教育以及社区建设上加大投入。Democrats的思路是治标的，fix the issue itself，枪支问题严重，所以要减少枪。Republicans的思路是治本的，解决犯罪产生的背后的问题（贫穷、教育、社区、精神健康）。

堕胎问题。

Democrats说，你们不允许堕胎，那些到了怀孕后期发现胎儿有健康问题的只能把小孩生下来，那些被强奸的妇女也只能把孩子生下来。允许堕胎，就能减少社会问题、减少单亲妈妈的数量。Republicans说，我们要加强对性犯罪的打击，加强对sex criminal的管理，减少强奸案的发生，我们要加强对青少年的安全性行为的教育，提供resource，减少teenager怀孕的发生，从根本上减少单亲妈妈的产生。Democrats的思路是fix the issue itself（把不想要的孩子做掉），Republicans的思路是治本（不要怀上不想要的孩子）。

平权问题。

对问题的本身，大家的理解是一致的：有一些人群（特定的ethnic group、特定的gender以及sexual orientation、以及按年龄划分、等等），是under-represented的。比如，高管和董事会里面，女性比例少；科技公司里面，女性比例少；科技公司员工和大学新生里面，黑人和Latino是under-represented的（相反，Asian是over-represented minority）。但对于怎么解决这个问题，Democrats和Republican的思路不一样。

Democrats的思路是偏equal outcome的，要Affirmative Action，在同等条件下优先录取黑人和Latino，甚至适当降低录取分数标准，提升黑人和Latino在大学新生里面的比例。Republicans的思路是偏equal opportunity的，要找到STEM里女性少的根本原因，解决这些根本原因，从幼儿园小学开始就鼓励、吸引更多女孩学STEM。Republicans认为，多年以来大学里面STEM的女生比例就一直很低，关键要解决这个源头问题。

最低工资（Minimum Wage）。

Democrats说，要让低收入人群日子过的更好，我们要把最低收入从每小时12块提高到每小时15块，这样低收入人群的收入就提高了。Republicans说，你们表面上提高了最低工资是能增加低收入人群的收入的，但提高最低工资会增加business的成本，hurt了business招人的意愿，反而会hurt到低收入人群的饭碗。Republicans说，要让低收入人群日子过的更好，还是要发展经济、增加就业。Democrats的思路是治标（钱不够就加钱），Republicans的思路是治本（把经济搞上去、把蛋糕做大）。

难民问题。

Democrats说，难民好可怜，无家可归，流离失所，所以我们要一起来接收难民，让难民在我们的城市里社区里安顿下来。Republicans说，你们接收这些难民，不解决本质问题，本质问题还是要让那个地方尽快结束战乱，让难民有家可归。

医疗问题。

Democrats说，看病太贵了，所以我们要让每个人都有医疗保险，我们要强制每个人都买医疗保险，因为所有人都买医疗保险了，医疗保险的保费才能降下来。Republicans说，看病贵，要从根子上找原因，要找出来为什么看病贵，要降低药品价格，要在医疗行业引入竞争，要让医疗费用更透明，用市场的手段让价格降下来，让大家都看得起病。

毒品问题（Drug Overdose）。

有些瘾君子，吸毒吸多了，注射过量，就挂掉了。Democrats的做法是由政府提供注射毒品的场所（safe-injection site），这样万一overdose了可以及时救助，就能减少因为overdose而死掉的人数了。Republicans说，关键还是要解决毒品问题，要从根子上解决Opioid Crisis，要war on drugs，要加大打击drug dealer 的力度，要加强处方药的管理。

虚假信息（Misinformation）。

Democrats的做法是要求Facebook和Twitter加强管理，对于传播虚假信息的进行删帖、封号。Republicans的思路是：“The best cure for bad speech is more speech. Over time, truth will prevail in the marketplace of ideas. And rather than silencing false or dissenting views, respond with truth and win the argument.” (《One Vote Away》，Ted Cruz，2020）

不过，也有一些问题是反过来的，Democrats的思路是“治本”，而Republicans的思路是“治标”。例如：

制造业工作（Manufacturing Jobs）流失的问题上，Democrats说，既然制造业的工作流失到其他国家去了，我们就应该顺应时代大势，进行产业升级，我们应该投入资源对这些下岗员工进行重新培训，帮助他们适应新型产业的新型公众的要求，帮助他们在新兴产业里重新就业。这听上去是一个比较“治本”的思路。而Republicans的思路就比较“治标：制造业工作流失了？那就把制造业工作再搞回来。

Border security问题。Republicans的思路看着很“治标”：建一道墙，把偷渡者给拦住，加大对ICE的投入，加大力度遣返非法移民，尤其是有犯罪的非法移民。Democrats的思路是“open boarders”，开放边境，同时不再管非法移民叫illegal immigrants，而是改成叫undocumented immigrants。Democrats的这个做法听上去比Republicans的做法更加“治本”一些。

还有很多社会问题，不太好说谁是治标、谁是治本。比如，低收入学区的公校教育质量低的问题。Democrats说，我们要增加税收，把多收来的税用于加强这些学区的公校的建设。Republicans说，我们搞school choice program，这样可以引入竞争，用竞争来促进公校自身的提升。

其实，仔细想想，Democrats和Republicans之间这种治标和治本的区别，其根源也许并不是意识形态或者方法论层面的，也并不是谁比谁更聪明能干。其根源也许很简单：治标见效比较快，治本见效比较慢，如果希望能尽快解决、尽快看到成果，可能就会倾向于选择治标的方案，如果不那么迫切的想看到成果，可能就会选择治本的方案。

//the end

冯佳说，类似Geranium这种餐馆，不吃要后悔，吃了更后悔。她说，后来去欧洲，她们开始走苍蝇馆子路线，到也不是绝对不吃米其林餐厅，但绝对不去以分子料理著称的米其林餐厅。

之所以会聊起Geranium，是因为今天我给她转了一篇说甬府的文章，文章的标题是《上海米其林抄袭事件》，说的是甬府抄袭了Geranium的几道菜。作者吐槽甬府作为一家米其林一星，抄袭的是另一家米其林三星，而且还抄得那么丑。冯佳看了我转给她的文章，说她也去过Geranium，是2013年去的，那时候Geranium还没三星，还是二星。她说，“感觉前前后后差不多，反正一个感觉就是不知道自己吃啥了。”

米其林我也吃过几家，在上海，也在米兰、法国、纽约。的确都没啥印象了。有印象的就是纽约的Hakkasan，印象就是没留下啥印象 :)。写这段话的时候又查了一下，好像这家Hakkasan没有星星了，TripAdvisor上有条评论说“Not a surprise they lost their Michelin Star”。

这些年，印象深的，真的都是苍蝇馆子。

比如，2005年的时候在越南，那天在惠安吃的一碗Cao Lau（操劳？），觉得好吃的不要不要的。后来在上海、美国等地的越南餐厅想再点一份，菜单上都找不到Cau Lau这样东西。去年去越南出差，没去惠安，去的是胡志明市，但也算是多年后故地重游了，在胡志明市四处寻找Cao Lau也没找到。是不是真的要再去一次惠安，而且要再找一个一样的阴雨绵绵的天气，才能在那个巷子口再吃到那碗Cao Lau？

记忆中吃过的最好吃的burger是在西雅图的一家Keg吃的。那家Keg在east side，在靠近520那边的Lake Washington Blvd边上，在一个加油站后面那条小路拐上去，开一条上坡才到。那是十年前了，2010年和陈思政一家一起去吃的。我到现在还记得那只burger的味道，好juicy好juicy的。那只burger让我明白，原来burger也是可以很好吃的，麦当劳和汉堡王的汉堡根本不能叫burger。

后来那家Keg关掉了。Keg是一家连锁餐厅，就类似中国的俏江南或者巴国布衣。后来去Whistler滑雪，Whistler镇上有一家Keg，我们也去吃过几次。那家Keg的花椰菜很好吃，但汉堡就没留下什么印象，没有2010年第一次在Keg吃到burger时候的那种惊艳的感觉了。

但我的favorite还是西雅图的Veraci Pizza，基本上是all time favorite，能与之匹敌的可能只有中山医院边上早餐铺子的糍饭糕和咸豆浆。哪天如果要我去移民火星了，让我可以自由选一顿在地球上的最后一顿饭，我会在Veraci Pizza和中山医院边上的糍饭糕和咸豆浆之间纠结一下。纠结的结果可能还是会选Veraci Pizza。这是我吃过的最好吃的pizza。而且一定要点白底的（garlic base），topping要选asparagus、artichoke、procuitto。Asparagus提供了crunchy的口感，artichoke鲜嫩多汁，procuitto提供了咸鲜味。吃之前再撒一点dry red pepper flakes，再加上薄底的焦糊味和脆劲儿，那就是最好吃的pizza，比我在意大利吃到过的所有pizza都好吃。

那家pizza也是偶然发现的。那时候郑轶嘉还小，那时候基本上每个周末都会有一天我带郑轶嘉一大早就出来玩，好让他妈妈好好睡个觉。那时候带郑轶嘉去的最多的就是西雅图的动物园（Woodland Zoo Park）。在动物园晃到中午，就找动物园周围的地方混顿午饭。有一次就找到了Market Street上的这家Veraci Pizza。郑轶嘉也很喜欢吃这家的pizza。他不记得这家店叫Veraci Pizza，他管这家店叫“动物园匹萨”。在杭州这两年，我和他时常会想起这家店，想起那些年我们逛完动物园在那里吃的匹萨，说好下次来西雅图一定下了飞机就直奔“动物园匹萨”。

在我的favorite list上能和Veraci Pizza匹敌的可能只有中山医院边上早餐铺子的糍饭糕和咸豆浆。那也是十几年前了，我妈在中山医院住院，装颈动脉支架，有几天我就在病房陪过夜，天亮了我就下楼到对过医学院路上的早餐铺子吃早饭。每次我点的都是咸豆浆、糍饭糕。有时候也会点油条和麻球，但咸豆浆和糍饭糕是每次必点的。后来，来美国了，每次回国，因为有时差，每天早上都会很早醒。因为早餐铺子开的早，而且医院边上的早餐铺子开的尤其早，每次倒时差的时候我就去中山医院边上吃早饭。每次都点咸豆浆和糍饭糕。

有一次回国，带我妈出去吃饭。去的是甬府。对，就是那家抄袭了米其林三星餐厅Geranium的米其林一星餐厅甬府。那时候Geranium还是二星，那时候甬府还没星星，因为那时候米其林还没给上海的餐厅发星星。甬府，主要是环境好，老锦江的那个调调，就在向明中学那边，卢湾区的。

那天吃了啥，不记得了。记得是那天太阳特别好，我妈站在窗边，晒着太阳，我给她拍了这张照：

今天是2020年8月27日。我妈妈是三年前的8月27日去世的。我很想念她。