如何评价王垠在微软「罢工」？ 第1页

王垠成为今天这样，很令人惋惜。

我本科学化学的时候就听说过王垠，那时候我一行代码也不会写。几年过去，如今我平均每周写40小时代码，从AI到NLP到前端全都涉及。Apple的产品换了好几代，微信早已比QQ更流行，国内外的互联网巨头也已经换过几把交椅。而王垠好像没变，连抱怨的语气和理由都与当年退学时类似。

我一直觉得王垠的名气和当年退学引起轰动害了他。记得看过一个理论说起年少成名的危害就是人的心态和状态就会留在成名辉煌时而很难成长。所以这大概解释了王垠的心态为什么这么多年一直这样。只要发文抱怨就会引起关注，在别的方面不能带来心理满足和成就感时，这些关注就好像毒品一样能带来快感。当然我不了解王垠本人还有怎样的苦衷，大家可以觉得王垠这样是不忘初心stay young.

时间过去而人还留在原地，这种事只适合长者而不是年轻人。

王垠在 craftsmanship（手艺）和 engineering（工程）这一纬度上缺乏灵活性而且看起来只能做 craftsmanship。如果你看他这篇《一个人的罢工》（ www.yinwang.org/blog-cn/2017/04/11/strike ）和里面链接指向的另一篇《更新》（ www.yinwang.org/blog-cn/2017/04/06/update ），基本上他最不满意的事情就是自己代码写得比 Principal 好但自己只是 SDE2。我觉得对于这件事情观点可以有两种：

1. 因为王垠代码写得比 Principal 好，所以王垠至少应该是 Principal。
2. 为什么 Principal 要跟王垠比代码谁写得好？

如果你持有第 1 种观点，而且你不觉得第 2 种观点的那个问题值得问出来，那你可以不用看下去了，因为这个答案不是写给你看的，请你点左上角链接回到知乎首页找别的东西看吧。

我的观点是 Principal 不需要代码写得比王垠好，因为别人有更大的问题需要解决，而解决手段有很多种。写代码或者不写代码，写好代码还是写烂代码，这些都只是解决问题的手段而已，别人需要考虑的是什么手段更适合解决这个问题，而不是跟王垠比写代码。

很多人不明白一家大公司是怎样来运作的，打个比喻来说：国家主席需要思考这个国家未来几年的发展方向是什么，思考的结果可能是「我们要继续提升这个国家的竞争力，尤其是经济上的竞争力，因为未来几年很有可能还是和平，为此这个国家应该制定如下经济增长目标」。接下来他就需要看各个部门如何能够作出相应的贡献，使得这个经济增长目标能够得以实现。铁道部长可能会说，「如果经济按照这条曲线增长并达到目标的话，我们必须预期旅客和货物的运送量按照这样的曲线增长，因此铁道部要制定如下的运力增长目标。为了实现这个目标，铁道部需要增修这么多的铁路，需要这么多的预算，创造这么多的就业机会。」这些目标会被继续分解下去，有人负责某条铁路新线路的项目，有人负责这条新线路上一座铁路桥，有人负责这座铁路桥的施工……任务被分解得越来越细，当然最终有人要负责在把砖头从 A 点搬到 B 点。

大公司的运作方式是类似的：CEO 做的是战略层面的决定，例如 Microsoft 一开始的使命是「使得每张书桌上都有一台 PC」，结果这个使命完成了公司也赚了很多钱。然后各个 VP 要制定自己部门的战略来对 CEO 的公司战略作出贡献，例如 Windows 部门应该规划出 5 年后一款具有竞争力的 OS 应该是什么样子的，如何花 5 年时间做到。接下来 Windows 部门里面负责存储的人开始思考 5 年后的 OS 应该拥有怎样的存储系统——到时候用户的存储需求是什么、5 年时间的硬件性能提升能否满足需求、是否需要重新设计文件系统……任务分解到最后，肯定要有人负责战术问题，例如把某某算法写成代码。

现在值得讨论的是，如果有个搬砖的人说桥梁结构工程师砖搬得不如他好，并且觉得他才配得上工程师的职称，那接下来该怎么办？你先不要笑「为什么一个搬砖的人会懂得结构力学并且能够保证桥不会倒」，真正有意思的地方在于为什么这个搬砖的人不去跟铁道部长比搬砖？不去跟国家主席比搬砖？因为按照他的逻辑，国家主席搬砖也比不过他啊，为什么不让他来当国家主席呢？我觉得根本问题在于他对不同头衔的期望不一样。他心里清楚国家主席干的事情跟他干的事情毫不不相关，但他认为他干的事情和工程师干的事情本质上是一样的只是难度不一样而已。

王垠的问题在于他不知道 Principal 是干什么的，因此他认为 Principal 做的事情本质上跟他做的事情是一样的，从而推导出 Principal 代码必须写得比他好才行。然而 Principal 实际上要做很多他不懂得做也不懂得衡量事情，这些都存在于他盲点当中，所以他只能衡量他能够看得到的。这到底是谁的问题？我觉得个人肯定有问题但也存在系统性的问题。

首先说系统性问题。在我看来很多公司无法向不同级别的员工清晰解释职称体系中不同的级别对应的能力和责任是什么，以及员工要如何才能获得晋升所需的能力和责任。你思考一下：你知道你经理掌握什么你不掌握的技能吗？你知道你经理承担什么你不需要承担的责任吗？对于比你级别高的工程师，你又知道吗？其实很多人是不知道的，公司职称文档那几行字怎么读都读不出个所以然来。

这个级别要能够「设计和实现一个大型系统」，那个级别要能够「成功带领一个团队完成战略目标」，你来给我解释一下系统如何划分小型中型大型？或者说什么样的目标才算是战略目标？存在这种问题的公司不是个别现象，而是整个行业都如此。排除掉那些真心用职称来忽悠人的公司，正规管理的公司为什么不把这个问题解决掉？因为这是个普遍存在的系统性问题，没有办法解决掉。

程序员眼中理想的等级划分就如同数学考试一样：一年级学生懂得做加法运算，然而不知道乘法运算的存在。在他眼里，二年级学生必然在做更多的加法运算，或者对更大的数字进行加法运算。然后老师就会告诉他，「除了加法还有乘法，除了乘法还有指数，除了整数还有小数，除了小数还有虚数，然后还可以有向量和矩阵」。这时候学生就可以问老师「乘法是什么啊？」老师可以给他一本二年级课本让他自学去，如果他能把作业做出来那他可以跳级。这时候就不可能存在一个二年级学生质问「为什么我乘法算得比他快但他是四年级我只是二年级」。你有能力你可以跳级啊。那课本你确实看不懂，那作业你确实做不出来，那你就不要在这里吵了。在这个理想的世界里，王垠可以说自己就应该是个 Principal，让公司给他一个 Principal 才能完成的任务，然后证明他真的胜任，或者真的不胜任。

然而现实世界的职称体系就好像语文考试一样：你把一道高考命题作文交给一个小学毕业生写，他能不能够写？有些人可能直接被吓到了，觉得字数肯定写不够。但有些人会觉得自己能够写，无非就是要想办法增加字数而已，把作文写成长长的流水帐总可以吧？就拿经典题目「诚信」来说，对于一个小学毕业生来说，诚信可能就是「妈妈说我在做完作业之前不能玩游戏，所以我就拼命先把作业完成了，而不是偷偷去玩游戏」。你可以说这离高考命题作文的要求差太远了吧，但一个小学毕业生确实不知道差在什么地方了，因为他无法理解。在他看来他给出的答案就是对题的！同理，如果给王垠一个 Principal 任务，比较好的情况是他直接意识到自己做不到，比较坏的情况是他觉得自己做得到并且还真做了，只是结果跟 Principal 能做出来结果相去甚远，然后他还是不理解为什么自己不是 Principal。

说完系统性问题再说个人问题。很多程序员总是不愿意去理解跟人相关的问题，单纯地认为级别比自己高的人就比自己更厉害，级别比自己低的人就不如自己。这是典型的数学考试世界观。但其实这个世界就如同一个巨大的分布式系统，每一个人都是这个系统上跑着的一个服务，而且每一个服务都充满了 bug。级别比你高的人，只是一个吞吐量更加大的服务而已，不代表他们 bug 比你少。他们吞吐量大可能是因为他们的算法优化的好性能特别高，也有可能是因为他们能够把任务分发给其他服务来处理。

王垠属于那种性能超好的服务，估计能够接近单个服务吞吐量的上限。同时王垠充满奇怪的 bug，例如说他喜欢在 stderr 打印出一大堆信息来抱怨这个 assert 没有通过那个 assert 没有通过，但其实他能够 try-catch 所有这些问题然后继续跑下去。王垠不理解为什么 Principal 性能不如他好但是吞吐量比他高，因为这种情况理论上来说是绝对不可能发生的。其实这个「理论上」只发生在单机环境中，在一个分布式系统里你不一定要自己处理所有的任务，有些任务别的服务处理起来比你快多了，你可以交给他们来处理，前提是你能够正确识别他们的调用方式。

当然调用其他服务说起来简单实现起来难。有些服务的 API 设计得很不好，你发一个请求过去说「做这个任务」，然后收到回复说「这个任务不够有趣我要换一个任务来做」，那你怎么办？有些服务可靠性很差，同一个请求有可能秒回，也有可能永远不回，你自己要设一个 timer 来跟踪这个请求是否应该算作超时。有些服务看起来很可靠，还主动提供一个 event 来不停地通知你任务进度，但问题是这个进度到 92% 就不再前进了，让你觉得很想要重启这个服务，可惜你没有 sudo 权限。

一个吞吐量非常高的服务必须有足够好的算法来优化对其他服务的调用，甚至是优化其他服务之间的调用关系，从而提高一堆服务作为一个系统的吞吐量。在极端情况下，一个高吞吐量服务可以是一个前端 load balancer（负载均衡器），自己不处理任何实际的任务，但必须掌握后端所有服务的状态从而灵活调度。说到这里，肯定有人要跳出来说「某些人就是前端 load balancer，什么活都不干，就是抢 credit」。对呀，某些系统把 load balancer 去掉后也能跑，那你就应该把 load balancer 干掉啊。但某些系统把 load balancer 去掉后会导致后端服务雪崩，结果是你得不到好处还连累了自己。

回到我最开头说的 craftsmanship 和 engineering 的问题上来。王垠只专注于他自己作为一个单机服务的优势，而从来不考虑一个大型分布式系统怎样运作，这本质上就是 craftsmanship 和 engineering 的区别。拿木工为例子：我只需要做好我手头上这一件家具，把它做成艺术品，这就是 craftsmanship。我需要让这件家具做成适应流水线上的快速生产，并且能够在打包进集装箱时尽量省空间，最后运送到全球各地的 IKEA 销售，这是 engineering。

我之前也说过，王垠这样子下去唯一的出路就是找一个很重视他的经理或者高级工程师罩着他，只挑他喜欢的活给他做，并且照顾好他的心情保证他一直开心，让他一直高效产出。用直白的话说，王垠需要一个 load balancer 在他前面，这个 load balancer 能够在一个更大的范围内跟其他 load balancer 协调好，保证适合王垠做的任务总会路由到他这里来。同时这个 load balancer 还要能够正确的解读和过滤王垠的 stderr，只向上一及调用者返回真正重要的信息。不过考虑到王垠自己不理解 load balancer 的价值也不认为 load balancer 有存在的意义，所以这个问题很可能是无解的。

这个世界是一个网游，但王垠偏要当作一个单机游戏来玩，那不管你 PvE 打得有多厉害，你出了新手村就注定被 PvP 虐死。

P.S. 链接打不开的请自行使用 Google Cache。Google Cache 已经失效的话你自己想办法吧。