为什么国内 IT 公司 leader 以上就不怎么写代码，而据说 Google 的 Jeff Dean 还写代码？到底哪种情况好呢？ 第1页

国外的manager是不写代码的，写代码的是tech lead。

jeff dean不是manager，没有人直接向他汇报（也可能有少数几个）。

国内貌似经常manager和tech lead是一个人，技术管理一把抓。管理和招人很累的，写不写代码要看有没有精力了。

更新：据说jeff dean现在直接管ai部门了，但是几年前我在google实习的时候他好像不怎么直接管人。

国外的公司我没去过，没有发言权，我只说一个真实的故事。

有一次，我当时的leader跟我说：你知道吗，我今天写了会儿代码（停顿了几秒），真爽啊。。。

那种语气和表情，绝不是久旱逢甘雨，或者烟鬼好久没抽到烟点上根烟，或者饥渴已久不可描述之后的样子可以形容的。

所以我恶意的揣测一下，题主是不是想把国内公司批判一番？比如当上了leader就失去了艰苦奋斗的匠人精神之类的？

事实是，多数情况下，代码谁都能写，更多事情却不是谁都能干。这些事情和写代码比，有些是恶心，有是磨人，有些是殚精竭虑。

写代码，是小确幸啊。

最近面了一些国内的人后，我印象最深的是一位有着10年经验的开发。 他从名校毕业，在国内几家大厂工作过，还创过业。我们对他很看好， 但是最后没能让他通过。由于他的缺陷在北美很少见， 我一开始不太理解， 于是找同事和导师探讨其原因。最后我们的结论是：跳跃式升职。

• 首先，所谓跳跃式升职， 是指员工升职后，不去干之前职位的活了。
• 其次，跳跃式升职的公司效率会较低。
• 最后，这种公司中美都有。

像程序员升职了之后不写程序、不做运维， 就属于典型的跳跃式升职。 相对而言，非跳跃式升职后， 高级程序员也会少写一些程序， 但是不会不写。

不论是哪种升职， 都很少会让一个只会写程序的人升上去。跳跃式升职的情况， 有时候会需要人去干越级的活儿； 非跳跃式升职会需要人去转移侧重。

话说回来，其实这题我看了很久，一直不知道怎么吐槽好，直到最近面过这位开发之后。

一位奇怪的开发

这位开发简历很优秀。他10年间游走于各种国内大厂， 还创过业。 他做的项目看起来难度都很高。 这个过程中，他从基层一直做到了技术总监。 他毕业的学校是清北这类的， 虽然这么多年经验的人我们基本上不会看学校。

我们面他之前， 我还担心级别会不会给低了。 大家面完之后一讨论才发现， 不论是哪个级别我们都不能要他。

这位开发对于面试做过充分的准备。我们公司很多人头疼的Behavior Questions他也能对答如流。技术层面， 单个环节他也做得不错：给他问题， 他能分析需求； 给他需求， 他能做出设计； 给他设计， 他能写出程序。

但是我们发现一件很诡异的事情：每次他做完第一步， 就做不了第二步了。 比如给他问题， 他分析出了需求， 却无法根据这个需求做出设计； 给他需求，他做出了设计，却无法根据这个设计写出程序。

每次他都只能拿我们给的输入， 来得到下一步的输出， 而无法用自己的输出进行下一步。

我们拿需求和设计举例。 一般来说， 需求定义得越模糊、混乱， 设计时所需要的理解能力就得越高。 因为我们面试时给他的需求是明确的、清晰的， 所以在他能理解的范围内。也因此用我们给的需求他能做出设计。 而他自己分析出的需求， 是模糊的、混乱的。虽然他分析出的需求也不算太混乱、还在我们的理解范围内， 所以从单个面试关节而言， 结果不算坏， 但是却超过了他自己的理解范围。于是他自己分析出来的需求， 自己没法做设计。

也就是说， 我们给了他问题之后， 他对自己分析出的需求是没信心的， 甚至不理解的。他对细节也是没有把握的。 哪里难、哪里简单、哪里有风险、哪里没风险， 他根本看不出来。

在我们想更多了解他的经验时也发现，虽然他给的几乎是我们Behavior Question的标准答案， 但是他却不知道为什么要那样做。

虽然这样的缺陷不是没法更正， 但是招聘他对我们的潜在代价太高。 因此我们决定放弃这位候选人。毕竟开公司也既不是开学校也不是做慈善。

跳跃式升职

面试后的讨论中， 我们总结出了他的缺陷：他的不同抽象层的开发能力都是不衔接的，是有空隙的。

至于造成这种缺陷的原因，我们可以对比两种成长模式。

首先是我们熟悉的， 我们自己所在的公司的：

在我们这里， 从实习生开始就是一个人带项目从头带到尾。 从分析问题（甚至发现问题）， 到分析需求（更多是跟stakeholders沟通需求）， 到设计， 到写程序，都得做。甚至有些组的实习生会把设计分给别人实现。 都是实习生了还能分给谁实现？ 当然是分给高级开发。实习生设计的一般会比较混乱， 所以分给高级开发去实现，刚好能弥补这个缺陷。

实习生唯一不需要做的是运维， 因为毕竟实习时间比较短， 来不及学这些。

这样的开发升职时， 侧重会慢慢改变， 但是基本上只是项目更复杂了、需要的人更多了。不会出现职责上有不连续的地方。

我们这里的常见的问题， 是升高级开发后， 有些人没意识到自己的角色的转变、侧重的改变， 而过度把时间放在写程序上、没能更好的领导自己的组织。

总结起来， 我们不同级别的开发的职责大概长这样：

1. 实习开发：发现、分析问题，分析需求，写程序、测试和部署解决方案。做小问题，侧重执行。
2. 初级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案， 做运维。做小问题，侧重执行。
3. 中级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案， 做运维。做中型问题， 侧重辅导和执行。
4. 高级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案， 做运维。做大型问题，侧重领导和设计。

对比起来， 我猜测这位开发的经历就不太一样了。 我想象他的公司里， 不同级别的开发的职责也许是这样的：

1. 实习生只打杂、做运维
2. 初级开发只拿着别人给的设计写程序
3. 中级开发只拿着别人给的需求做设计
4. 高级开发只拿着别人给的问题分析需求

因为我没见过这样的公司， 所以我找了一位见多识广的导师问了下， 是不是真有这样的公司。他说有， 还不少。而且他说， 这种跳跃式升职恰恰是这位候选人的缺陷的元凶。

跳跃式升职的问题

跳跃式升职的公司里每次升职都是完全的角色转换。 每个人升职之后就不用干之前的活了。 所以会有人为了不做自己现在的一些活而去升职。甚至会有人因为现在做得不好， 所以才拼命升职、做上级的活。 而且大家也知道， 自己之前做的事情、培养的能力， 对于下个阶段都没有用， 所以对于积累是一种消极的态度。这些公司对于级别低的人、他们做的事情， 都存在一定的鄙视。

这种模式是低效的。 我们可以想象一位纸上谈兵、不用负责写程序的高级开发。 他做了一个设计， 而这个设计在底层执行时出现了问题。这种情况下，由于下面的人没有被赋能去自己做设计，修正问题是需要上报给他、让他去改设计的。 这大概率将会是漫长的、多层的、充满政治斗争的， 因为大家都想把责任推卸给底层执行者的无能。而且他由于不会去做底层的活儿， 很可能是不理解自己设计的缺陷的。

久而久之， 如果这个还公司活了下来， 你会发现越无能的人越在高层：如果底层的人无能， 它根本活不下来。它的高层因为长期脱离了项目底层的反馈， 根本就不可能培养出优秀的决策能力和领导能力。 所以他们必然会需要底层有优秀的人才才能让公司活下来。

我们公司很多高级开发最大的价值， 在于他们能够快速点出项目上哪些问题会对执行造成风险。 这意味着他的各个层次的能力必须是衔接的。

为了培养这样的高级开发， 我们必须给他们项目完整的反馈：也就是说他必须实现项目中一些高风险的部分， 分配一些他觉得低风险的部分给别人， 并且为这些决定负责（比如如果分配错了， 他是得负责的）。 如果他只做设计、不写程序， 那么他是无法拿到完整的反馈的。

根据Conway's Law， 软件系统往往会追随公司的结构。 如果公司结构上有空隙较大的分层， 那么他们的软件系统中也会有同样的分层。

我所在的公司， 大体上希望每个组的范围是垂直的：一个功能从用户体验到后台、到运维、到商务报告， 最好都属于一个组。这样修正问题会很有效， 不会多组之间有很重的耦合。

而跳跃式升职的公司， 往往系统不同的层是分给不同的组的。因为他们的员工只希望在一个层次工作， 所以系统也会这样分。 最后甚至会有专门搞数据库的组， 而数据库组跟后台业务逻辑是割裂的；后台跟前台也是割裂的。

最大的低效出在这些层的边缘上。 因为没人拥有完整的功能， 所以没人理解完整的功能。层和层之间的沟通也就往往是低效的。 为了解决边缘上的复杂度， 有些公司可能会再在后台和前台之间再加一层。 但是这只会让问题恶化：层次更多了、低效沟通也更多了。

美国为什么会有这样的公司？

对于国内我不了解。 导师提到，美国会出现这样的公司， 是因为有这样的市场：当你有一个项目找人做时， 你是会找一个100万给你做出来的大公司， 还是10万给你做出来的小公司？

导师说， 之前他们遇到一位VP是这么说的：如果他找了要他支付100万的外包公司， 项目失败了外包公司负责；如果他找了10万的， 项目失败了他自己负责。最后果然大外包公司项目失败了，退了一半的钱。 他们又拿这个钱去小外包公司把项目做了出来。

跳跃式升职的公司的产生， 源于对缺乏组织管理和人才培养的能力， 并盲目地进行专业化分工和分层。这种低效的分工和分层能正当化大量的人力需求， 把小项目说大。 而市场上恰恰又有人觉得， 一个项目100个人做风险总是比10个人做小， 而不仔细调查公司的开发模式。 最后导致这种低效的公司也能活下来。

其实很多时候人太多、分工太细会增加风险， 会产生“多单点故障”。

工作中我们有时会遇到自己或者他人对于“单点故障”这个概念产生谬误。比如一个系统， 它的某个服务非常重要。 只要这个服务挂了， 整个系统就挂了。 于是有人把它拆分成了三个服务， 号称这样就根除了单点故障。实际上， 这三个服务中任何一个挂了， 都会造成之前同样的效果。 于是我们的系统由有“单点故障”变成了有“多单点故障”。风险反而增加了。

而有些人把这种谬误也带到了分工中去。 他们发现有些人管得太宽、职责太多、少了这些人公司就没法运作了。于是为了保证公司不论缺了谁都能照常运作， 把职责掰开了分配给不同的人。 这显然是不对的：现在每个人走都可能造成一个空缺。这种分工反而是给公司制造了“多单点故障”。只有让多个人有重叠的职责， 才是少了谁公司都能正常运作。所以做法上不应该是根除职责太多的人， 而是增加这种人。

10个人的项目拿100个人去做， 往往最主要的问题是沟通问题。 其次就是分工太细， 导致多单点故障。 开发一个系统通常没有哪个组件是可以缺失的。 分工太细之后， 一个人的失误可以延迟整个项目。 人越多， 这种问题就越容易发生。一个例外是你把这100个人拆分成10个团队， 平行开发同一个系统。不过这样做很昂贵， 虽然降低了风险，但也是另一种低效。更有效的做法是小团队做迭代式的开发。

当然不是所有人都觉得项目越贵风险越低。但是只要有， 就可以养活一些低效的公司。 当然， 这是美国这边的情况。 美国科技大厂基本上没这毛病。美国这边问题主要出在大厂以外的公司， 比如传统行业、外包公司、还不太成熟的小公司。国内是什么情况我不了解。

总结

人才在培养过程中， 的确会出现侧重的转移。 但是责任上应该还是重叠的。 一个高级开发、首席开发， 可以少写程序， 但是不能不会写。 他需要能融汇贯通他各个层次的能力， 才能成为一个有效的领导人。

归根结底， 职业的成长应该是一种累积， 而不是一种跳跃。今天走的捷径， 有时会是明天的天花板。

其实即便是美国的科技大厂，即便就是Google，SEM/SDM一般也是不写代码的，Jeff Dean算是一个异类了

不止是Google，美国的这些科技大厂都会养一些纯投入不计产出的部门，他们可以（某种程度上）不受业务方面的压力，去做一些自己认为正确地研究。很多时候公司的下一个增长点就是从他们这些研究中出来的

但与此同时，公司也要生存，也要有部门不断地赚钱，也需要有很多程序员去写那些业务驱动的，面向客户的，不好玩但能赚钱的东西。对于这部分产出，manager专注于项目和人事，tech lead主要搞架构和技术协调，senior/sde2+主要搞模块设计和带小组顺带写点码，sde2-/sde1/junior是产码主力军，这种模式是已经被无数实践证明了能够持久地高效地运转的

想到我在微软的前老板，他就是一个纯技术出身，一路做到Principal Engineer之后转的Software Engineer Manager，你和他聊技术，会发现你懂的他基本都懂，当组里有一个事情缺人的时候，如果其他人实在脱不开，他立刻就可以顶上，写码，oncall，operation无一不精，而且oncall的时候能发现，他几乎是组里除了另外一个Principal Eng之外对组里整套系统最熟悉的人。人家之所以要做管理，是因为相比做技术，他确实更擅长管理，一个人带了其他同级manager三倍的人，还能把各方面处理得井井有条，组里在保持非常高产出的同时，work-life balance还非常好，而且还能不断地从上头那里给组里揽好处，这样的人作为管理者很难让人不服

我觉得有时候，做技术的不要过度局限于技术思维，不应该想当然地觉得“技术大过天，其他全是臭老九/骗钱的/吹牛的”，跳出来看一看想一想，为什么会有这样那样的业务需求，然后再想想怎么用自己的技术去更好地驱动业务发展，这个和技术本身并不对立，因为本质上，它和攻克技术难题一样，也是Problem Solving，甚至是更受大部分企业欢迎的Problem Solving

---

除了技术和业务的平衡之外，还有一个很重要的因素，就是好钢用在刀刃上

不排除许多大神就是喜欢写代码，但是因为一个公司的人员的能力划分往往是金字塔型的（能力越强数量越少），所以应该让能力强的人去解决“三高”（难度高，模糊度高，价值高）的问题，而让能力没那么强但数量多的人，更多地去做重复性，具体性的工作。

像Microsoft和Amazon这种比较成熟的企业，对每个级别的员工需要从事什么样的工作，比重大概是多少，都有非常明确的书面规定，比如SDE 1基本上80%+的时间都在写代码，而SDE 2写代码只占50%上下，Senior大概只有20%~30%左右甚至更低，Principal+完全没有要求。

同时，级别越高，其他方面的工作比重就会越高，比如和PM一起分析需求，定义限制条件，设计架构，选择技术栈/服务，拆分问题，和其他部门系统的owner探讨可行性，提升部门内OE减少tech debt，流程优化，培养新人等等

举例，我们部门的Principal，每天基本上60%时间开会是底线，很久才碰一次代码，每年提交也就几千行，但他但凡交了代码，要么是能解决整个部门长期痛点（比如一个bug反复出现导致系统不稳，他几百行代码交上去给修好了），要么是做了一个全部门都拿来用的pattern/prototype。这就叫好钢用在刀刃上

---

  babyquant 网友的相关建议: 
      

应该不是国内国外的区别，微软、亚麻可能很基层的leader就开始不写代码了，但一些高频交易、量化投资的，可能大老板还要写代码。

像Tower Research下属的Latour，大佬肯定要写代码的，难道把策略告诉别人，让后别人实现了给你交易？

比尔盖茨当微软首席架构师的时候肯定也是写代码的。操作系统没人比他懂。

Linus这种肯定也是一直写代码的。

而且本来Jeff Dean就是研究院的，每个人做自己的研究，他也有自己的研究项目，如果只做管理，听听汇报，给点意见，反而很容易被取代。

---

  tian-yuan-dong 网友的相关建议: 
      

团队最需要什么，管理者就做什么，这个是“负责”两个字的意义。

ELF OpenGo需要早点做出来，需要搭一个2000块卡的分布式系统，需要效率更高的多线程并行，需要各种性能优化，需要重新设计ELF和应用层的接口，需要分析算法跑不出来的原因……团队里新人多，时间紧，于是我就写了90%的代码，等到东西真的开始有效果了，士气自然高涨，项目自然可以做成，而团队就能带起来。之前的第一版ELF也是一样的。

其它的本职工作像看文章啊，科研讨论啊，联络其它组啊，招人啊，面试啊，那是一样也不会少的。

话说回来，不鼓励和员工抢活做这样的行为，这样就失去了组团的意义，也不利于员工的成长。等大家成长起来之后，就要鼓励员工做力所能及甚至是有挑战性的工作，而管理者就要面向更高层次、更重要、更困难的目标。这一方面符合对于管理者的预期，另一方面对自己的成长也有利，因为做别人做不了的，人才有价值。记得前两天有人问我为啥还有solo-author的paper，我说那是因为这样的方向难，学生们做不了也不愿意做，灌水大家都会，开新方向出新思路，才能体现价值。

---

  catchen 网友的相关建议: 
      

其实 leader 需要把精力集中在「团队中除了你能做别人都不能做」的事情上，无论在中国还是在美国都如此。如果团队的业务不成功，公司就会想办法解散团队，否则公司也活不下去。

作为 leader 要解决的不仅仅是团队内的难题，很多时候还是团队的 shit umbrella。在大公司里，永远都会有 shit 从四面八方而来，关键是要有人能挡，挡不住团队就会散。下面的人喊的是「公司傻逼」但离开的是你的团队。

至于某个具体 leader 是通过技术能力解决难题还是通过外交能力挡 shit，这要看具体的团队环境。有些团队，例如在已有云平台上做产品的，哪来那么多技术难题？不要做梦了。有些团队有多名不同角色的 leader，其中有些人把向上管理和向下管理做好了，自然有人有机会做技术。总之，团队的瓶颈在哪里 leader 就应该做什么。

---

  xu.liang 网友的相关建议: 
      

这个例子很好地反映出了中美，甚至是东西方社会组织模式的差异。

从古至今，中国社会最顶尖的大脑极少会专注于科学技术本身，治国平天下才是君子的最高人生追求。哪怕做不到治国平天下，独特的民族性格也会驱使顶尖人才成为各行各业的管理者，而不是业务能手。

最优秀的人才集中在管理和组织领域，使得在同等技术水平中，中国社会的组织力和生产力要远超大多数文明。

尽管生产力极度低下，古典中国依然有能力组织起几十上百万人进行各类大型工程。修建长城、开挖运河、兴修大型水利设施，这背后的管理成本和组织生产的难度，哪怕在现代社会也不是每个国家都可以驾驭。

甘蔗没有两头甜，高组织度的代价是创新能力的停滞，和科学与理性思维的缺乏。科学领域最需要顶尖的大脑进行突破性的创新，一万个帝王将相摞一起，也赶不上一个普通科学家的贡献大。

高组织度最害怕降维打击，害怕科学技术和生产力被碾压，高组织度的优势在降维打击面前一文不值。

文艺复兴以及第一次工业革命后，西方的科学技术和社会组织模式大幅领先中国，这种代差完全没法依靠高组织度来弥补。

再强壮的肌肉，力量也比不过蒸汽机；再听话的奴隶，效率也赶不上织布机；再娴熟的弓马，战场上也要被燧发枪和刺刀碾压。

科学技术领域创新突破需要最顶级的人才，但学习和应用只需要普通的人才。牛顿和爱因斯坦都是百年不遇的天才、开宗立派的宗师，但大部分人经过系统的学习，同样可以掌握经典力学和相对论，甚至在一些解题技巧上，吊打牛顿和爱因斯坦。

当中国遭遇科技降维打击时，只要没被一波直接打死，中国社会的一流政治家们很容易组织起大批的二三流人才积极向高维文明学习，在科学技术领域迅速追赶。

这也是我们过去一百多年的小小总结。西方自文艺复兴开始，通过启蒙主义、浪漫主义等思潮解放思想，引领三次工业革命对全球各文明形成科技代差。

中国一直在紧紧追赶，但西方文明进展更快，过去两个世纪连续多次取得重大科技突破，一直牢牢保持着对全球的技术代差优势。当中国可以自产枪炮，西方的铁甲舰队已经在四海纵横；当中国好不容易可以生产现代军舰，西方已经将宇航员送上太空。

最近几十年，全球科技发展大幅停滞，第四次工业革命遥遥无期。西方越来越难保持对中国的维度优势和技术压制，当中国和西方接近到同一维度，哪怕技术水平略微落后，依靠高组织力的优势，中国也能在各个领域卷死西方。

最典型的例子莫过于疫情。如果中国对现代医学一无所知，靠着传统阴阳五行那一套，组织度再高在病毒面前也是毫无还手之力。但当中国和欧美站在同一起跑线，即使中国在医学技术上略微落后，依靠强大的组织度，中国防疫的表现依然远优于欧美。

作为科技领先者，欧美要持续保持科技的代差会非常困难。因为技术总会不停地从高处扩散到低处，科技发展一旦停滞，领先者和追赶者的差距会迅速缩小。

又比如芯片行业，原理并没有特别的神奇之处，如果欧美芯片加工工艺长期停滞在5nm的水平，被后发国家追上也只是个时间问题。

回到提问本身，Jeff Dean作为这个时代最优秀的大脑之一，确实是一位厉害的工程师和科学家。但作为个体，自身的能力终究有限，亲自下场干活，又能研发出多少东西呢？

我自己曾今在谷歌工作多年，对于谷歌内部技术比较熟悉。谷歌很多技术方案业界领先，在AI和大数据基础架构方面更是独领风骚，但离形成技术代差还差得很远。

就算研发出了Alpha Go，本质上并没有突破性的创新，也没法树立起难以逾越的技术壁垒。中国对应的一流大脑只需通过一纸文件，就能引导无数青年教师、博后进入AI学界，通过人海战术活活卷死Jeff Dean。

中国企业的管理者往往比欧美企业更早地脱离一线业务，是我们民族性格的一个体现。这固然会对研发深度带来负面影响，但却能有效地提高工程效率和组织程度。

这个时代不属于Jeff Dean，早生一百年，或许他可以是另一个麦克斯韦，依靠小团队甚至单打独斗就能做出突破性的创新，给生产力带来质的飞跃，为所处文明带来难以追赶的技术优势。

西方文明自由散漫，创新能力强，擅长从0到1的颠覆性突破；东方文明等级森严，生产效率高，擅长从1到100的精细化管理。科技停滞的年代，反而对东方文明更有利。

当技术没有代差，让最优秀的人才专注于压缩成本和提升效率，才是这个时代卷赢对手的不二法门。

---

  leon-3-75 网友的相关建议: 
      

年轻人你误会了一个公司运行和管理的机制了。

作为一个it公司的领导来说，他写不写代码无所谓，这个公司能不能源源不断的产出优秀的代码才是重要的任何工作，最后评价领导者水平看的是结果，而不是看这个领导能不能身先士卒。

这个领导哪怕不会写代码，他只要能管好写代码的团队，源源不断的产出好代码，那就是个好领导，相反这个领导自己写代码能力无比出色，但是他一个人又能顶几个程序员呢？

所谓在其位谋其政，你在领导岗位上首先做好领导岗位该做的事情：掌握大方向，知人善任，制定计划，控制进度，事后评估，掌握激励政策等等…在做好这些东西的基础上，你自己爱编程，爱身先士卒，随便你。但你要明确你编程水平的好坏，你爱不爱编程，你是不是身先士卒，并不是评价一个领导好坏的标准，前面那些控制工作做的好不好，这些才是评价领导好坏的指标。

所以你会看到有的领导编程写代码，有的领导不编程写代码，到底哪种模式好？写不写代码不重要，谁把公司管好了谁就是好。

---

  lu-luce 网友的相关建议: 
      

因为国内的IT都不是技术驱动型公司。大家都是圈一块地，吃人口红利的租金的。

真正技术型驱动的IT团队，就是要编程。就好像前段时间过世的袁隆平院士说的：做我的研究生必须下田。

---