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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一个技术leader最重要的职责，明面上是组织团队用技术手段对公司的经营做出贡献，暗面是要保证技术团队的生存。

在国内it公司，要保证一个团队的生存，他第一要做好向上管理，跟踪分解领导战略，频繁汇报进展，隔三差五拿出让领导出去能吹牛逼的东西；第二要做好部门协同，与业务部门共同进行业务创新，打造亮点，让业务侧有人为他说话；第三要创建和运营技术团队运作机制，一方面保证交付质量，另一方面还要关注团队稳定和员工成长；第四还要处理各种杂七杂八的事情，各种会议，约谈，喝咖啡，规划，总结，复盘，竞品分析，行业研究……

你觉得做完这四件事，这个所谓的技术leader，还有多少精力能用来写代码？话说回来，他就算把所有时间都用来写代码，有助于保障团队生存和发展吗？

国内技术leader不写代码的原因很简单，公司不够专业，导致他事儿太多，本来应该好几个岗位做的事情，一个人都得兼顾（尽管很多时候是低水平兼顾）。实际上如果一个技术leader整天写代码，那他多半是“本职”工作（其实好些事儿本来不是他的本职工作，但没办法）做的不到位，而不是能力强。

国内业务线的技术团队普遍存在这个问题，以之前阿里国际化电商的团队为例，老板懂业务会攒局的重要性远远大于深入任何一个技术栈。这个团队是19年一波人从淘宝转岗过来的，复制了淘系的用增框架，当时的一级主管在项目还没落地的时候是一起写代码的，二级主管则完全是把自己当产品用。不得不说，大家“业务先赢”的策略，不论是向上申请到更多的年终奖和晋升名额，向下给团队成员更多安全感，都是很有用的。至于技术，只要不是rocket science, 确定排期和优先级以后实现的问题就是一线大头兵考虑的。因此我们可以看到，国内这些公司特别擅长短平快的微创新，在增量放缓以后就开始以侵入用户体验来增加自己的KPI。

前几年也是从淘系起源吧，出了个pop layer，也就是应用内置弹窗，从此以后一大波人找到了提高用户转化率的抓手，在各个app和web端大肆投放pop layer，养活了挺多团队的，但是用户体验非常差。

去领英以后发现，技术基本不再背负业务增长的KPI，能看到内部很多对于系统架构的优化。同样的Java技术栈，我很惊讶这里竟然不再是国内Spring那一套了，也不像阿里花个20年升级到jdk8，就再也不敢升级了。Spring是很优秀，优秀到我习惯了它是空气，可没想到竟然有人想要替换空气，并且这个行动5年前就开始了。为什么？因为在领英的业务体系下spring显得笨重且不灵活，当可以改进的地方多了，就有人提出了全新的框架来替换。这里的框架并不是国内那些公司所谓的框架，阿里内部封装的框架不计其数，难用坑多且大多只是简单对开源技术的包装。领英的框架是真正全方位的优化，并且会推出专门的学习课程，先视频讲课讲原理，再有sample code的Lab实操，最后结合已经到生产环境的代码让你像在学校学习一样完全掌握。从一级主管到二级主管都说非常支持我们对于技术的探索，如果觉得工作不具有挑战性欢迎随时沟通。更重要的是每周有两次和一级主管一对一交流的时间，会聊业务、技术、成长、晋升、考核、生活、爱好等各种话题。相同的内容，我在阿里的时候，只有到我提出离职的时候，主管大吃一惊下才抽出时间跟我聊了一个小时。以人为本应该怎样践行可见一斑。

在阿里的时候，看到内部消息中间件MetaQ的研发文档说，MetaQ团队当时也是在领英的Kafka开源以后有所借鉴，这其实就是国内公司最常见的情况。而领英作为一个做职场社交的公司，全球员工不过两万多，也是靠业务吃饭不是靠硬核技术，但是就我见到的内部技术氛围和创新含金量来说，已经秒杀阿里。

再说说项目管理，阿里的项目管理基本为0，还停留在原始的农耕时代。一个产品的提出先有产品设计是正常的，但更多是技术为了自己这个财年翻倍的业务KPI压力提出的一堆短平快创新。要不是每个代码变更需要自己在AONE平台上创建需求，恐怕很多都是直接开搞。哪怕是一个稍微正式点的项目，流程是产品评审->技术评审->实施，看起来挺正规是吧？其实根本没有固定的进度追踪仪式。要是重要的话产品三天两头找你拉通对齐，不重要的话自己琢磨。当时入职了新的PM，该PM风风火火出了一套新的项目管理形式，也就是要到AONE上怎么怎么操作，怎么更新，然后拉了一个几十人的会告知大家，结果没隔几天就没人再理这些流程了。

上面是很真实的国内互联网大厂现状，可怕的是在那个环境下看不到一丝改进的希望，哪怕是我自己当时也觉得大家都这么忙了怎么可能还引入一套项目管理程序增加大家的负担？并且你知我知一段时间后没有人会在意，直到去了外企才打开了思路。这就是结果导向和过程导向的差异。外企也不是纯过程导向，外企的Manager会非常非常忙，这点和国内截然不同。国内大都是想混上去管人做人上人，手下有人给你压榨了就不用担心被优化了，而外企Manager的角色是要去做一个规划者，需要你规划好产品和手下的人，有大量的精力放到这上面，并且需要承担整个团队产出的结果责任，因此自愿加班的也是很多的。总的来说，外企的管理者有非常清晰的管理流程（正是因为流程化，可以部分避免由于老板个人偏好等主观因素造成的问题）需要他们实践。

外企大多是Agile开发，非常重视仪式感，会有专门的PM拉站会，项目开始的时候规划好一堆JIRA ticket，然后每天将todo, in progress, resolved的状态标记好，并且PM需要了解各个ticket有没有blocker（卡住进度的东西），如果有的话，会不会对下一个sprint（两周为一个sprint）产生dependency，并且会联系到责任方看能不能提供其他帮助。看到了吧，PM的核心在于督促和让你专心做自己手里的事儿，其他统统交给他。比起阿里午饭后2小时候午休，晚饭后遛弯再慢悠悠地回工位开始写代码，外企8小时不到的工作时间下效率高了太多。Agile还有一个好处就是在一个scrum团队成型后，可以让不同职务的人并行前进，每个人都专心于当前手里的JIRA ticket，开发写代码，测试测试，PM跟流程，产品出方案。这样不会像阿里一样，每个人都在思考怎么做所有的事情，比如测试天天思考搭建自动化平台，该测的业务却叫开发自测，开发除了开发还得绞尽脑汁思考产品。而实际情况还要夸张很多，阿里往往开发测试产品运营甚至UX都在思考怎么提高同一个KPI。

上面说的项目开始前规划好JIRA tickets，这在领英就是一个staff engineer(P7-P8)的要求，即你对这个系统非常熟悉，并且有看到全局的能力将任务拆分下去让更基层的工程师能够独立完成。如果没有和老板的沟通，根本不会认识到这些问题。你要做manager的前提就是你要先成为staff engineer，而在阿里大多数人哪怕升到P8了估计也是业务能力牛逼，和技术无关。

尽管老说外企怎么怎么样，其实我更认为这是现代化企业的形态。那就是职责分明，企业架构需要演变到缺谁都能正常运转，而让不同的人承担不同的责任就是最好的办法。而国内这些所谓大厂要求所有人都要背负同一个KPI的情况下，仿佛被判了无期徒刑，各个累得要死，花了很多精力在招聘、调研、PPT上，自身的技术基本没有什么成长；老板只想着招新人来带来业务输入，哪怕新人一年半年就离职也无所谓，让工作变成了折磨，实际不过是为低下的管理水平买单罢了。（只针对业务团队的开发工作体验哈）

在离职前几个月正好我们部门空降了个技术P9，发了匿名问卷，我也提交了基本如上述的一些看法，很快就收到全员消息，大致意思是：尽管不同岗位的人承担同一个KPI，但总有一个借东风的问题。具体你对这个项目贡献了多少还是看你自己的付出，实打实的进步别人蹭不到。让大家还是踏实思考怎么提高KPI。搞笑的是问题根本不在于谁蹭谁的功劳，而在于分工混乱。你进来就让我干招聘和调研的工作，怎么不面试问呢？反而翻出82年的题库问StringBuilder和StringBuffer有什么区别，打着阿里技术的旗号招了一批又一批韭菜。家安在杭州或者小公司过来的自然是拼了命给你干活（是真的能卷），但凡有点能力愿意搬到其他城市的都很快就走了。阿里没有神话（哪怕是19年口碑巅峰），hc多的时候管你是三本二本，只要能干活且听话就招进来。

总有阿里的老人对内外网对公司的抨击不屑一顾，觉得有人的地方就有江湖，阿里给你的教训是很有价值的，殊不知只是将一批又一批的少年变为恶龙罢了。公司不对人性的弱点加以限制，反而高举末位淘汰的鞭子让大家挤得头破血流，实在是管理层尸位素餐不思进取的表现。微软摒弃361以后股价连连新高，别人玩剩了的玩意儿这里被当成了宝。处处反映着管理层生怕不能压榨最后一滴剩余价值的心理。

所以总结一下答案就是，国内大多数是进行微创新，老板思考怎么进行，怎么快速推进，怎么拿更好的结果，怎么不给自己设边界远远重于技术的迭代。国外同样进行微创新的公司，由于公司组织和绩效考评相对合理，分工明确，不用时时刻刻逼自己跳出舒适圈，因而可以在自己的领域深耕。

Jeff其实不算tech leader了，他现在掌管google reseach，手下好几千人吧。不过他确实还是写代码。上周去google visit，订的会议室在jeff工位边上，至少我在那里的2个小时他一直在跟人pair coding（另一个人似乎是sanjay）。

不过jeff算异类，属于精力特别好的类型。我觉得不能当作正常例子使用。只能是学习的榜样。

过去一年我聊过很多40岁上下的senior 工程师，有些title还挺高，intel vp啊Samsung xx部门 chief scientist之类。但感觉下来，不管你能管多少人，职位有多高，如果不能坚持写点代码，那很有可能技术上会落伍。也许讲大方向头头是到，但如果问点稍微具体点的问题，那就只能蒙了。

我认识的不怎么写代码的老大，要么是更擅长管理而非技术，要么是太忙导致没时间写码。前者可以理解，但后者我倒是觉得浪费时间在一些也许不重要的事情上了。

#高管写代码#

谁耐烦给你们画一堆图写一堆文档。

直接写代码最快最简单好吗。

打腹稿的时候直接自己就写好了，先跑通了原型再开会。

原型没跑通之前，老子自己对业务模型也没想明白，vision都还没有，开什么鸟会？

开个会算算所有成本一小时几万几十万美元，净闲扯皮。

商量个球啊商量，没得商量。

下面这一帮也一样，你有什么好点子，拿出原型来跑给我看。

老子不看ppt。

想做到做不到那叫退而求其次，做得到不去做这叫自误。

一个真正伟大的开发项目在实质上只能是写核心代码的人主导的。其它“职位更高”的“领导者”只不过是高级服务员。

以上。

因为Jeff Dean自己不写这些核心代码，那么世界上也许就没有第二个人能写出更好的答案了。

刚好自己最近就在写谷歌Sanjay Ghemawat的 tcmalloc的对标代码，做自研C/C++内存分配库，对标的是Google Tcmalloc库(Google著名的大牛Sanjay Ghemawat开发，Jeff Dean的搭档，The Google File System的第１作者，也是著名的MapReduce论文的第2作者)，写得非常艰难。主要难在性能优化，谷歌这两位大神的代码虽然是十多年前的作品，细读下来，各种corner case的细节上，包括各种技巧的把握上，每一处细节都不浪费开销，一个内存分配库硬是几万行代码没有什么地方有硬伤，这就是顶级程序员最厉害的地方，这部分代码比那个时代同期的几个内存分配库性能高出几倍，挺传奇的。顶级程序员的功力，一般程序员给他再多时间再多人力，怕也是很难实现如此高性能的内存分配库。

近十多年，IT行业的软硬技术进步也是非常巨大的，所以考虑尽量用全部最新的软硬件技术，也许能快一些。目前正在写的自研内存分配库，已经完成的代码已经比tcmalloc库快了，重点是新增自动支持NUMA按cpu node分组分配内存(尽量分配近端内存，近端内存比远端大约硬件上延迟时间低三倍)，自动支持hugepage2M/1G(自动将hugepage切成小片分配，访问速度更高)，支持C++11中默认16byte对齐，SSE指令更加完美的支持。其它目标是更稳定平滑的内存申请释放时间开销，更小的内存碎片，更小的内存浪费。

从今年三四月份开始做，中间有其它一些小产品开发，所有代码均从头开始写，主要思路是尽量多使用CPU硬件新特性，一点一点覆盖掉tcmalloc库的功能，最核心的代码已经写完，还剩几处corner case，小规模测试中，在启用hugepage 2M的场景下大规模小字节块有接近一倍的性能提升，其中大部分来自于hugepage 2M的带来性能提升，所以计算机硬件本身的提升是根本，算法艰难的改来改去只带来了小部分的提升，测试16字节1000万条内存申请后再依次释放，平均每次申请13ns,每次释放7ns,每次申请+释放总体在20ns, 对比tcmalloc大约35ns。后续正式版弄完后，会放出一个二进制库的评估测试版，以及写一篇小文章简单介绍一下主要优化。一句话总结就是软件更好的支持硬件新特性，带来了性能提升。

国内大多数公司的技术领导最应该做的三件事是：向上管理、架构设计和项目管理，写代码可能是其最简单也最不重要的职责。

国内大多数技术写的代码，都是民工砌砖一样的代码，在整个技术框架、方案确定的前提下，只要是个合格的程序员，基本都能写出来，顶多是快点慢点，优雅点lowb点的区别，最后也可以通过CodeReview坳回来。

而国外很多技术大牛写的代码，是开创性的代码，就像是艺术家在搞创作，这种情况下你带太多菜鸟反而拖后腿，不如自己一个人搞，或者几个大牛合作搞。

我是个技术管理者，说说看法，国内的公司管理者是干嘛的？

其实通俗点讲，重要的职能有下面几点：

1.能搞得定人，怎么通过HR招到自己团队需要的人；怎么快速的让新人能上手干活；怎样营造气氛，打造有战斗力的团队；怎样留住能力强，蠢蠢欲动的年轻人，这些都是管理者需要搞定的人事；

2.能搞得定事，上级领导交办的事情，怎样能保质保量的完成？全是自己团队的任务容易，但是如果涉及到很多跟外部单位，或者其他部门，完成任务就没那么容易了，沟通协调必须做好；

3.能搞到项目，怎么把价值高的项目能拉到自己团队来做，让手下的兄弟能有学习成长的机会，狼多肉少，这个得自己不断去争取；

3.能搞得到钱，手下兄弟们辛辛苦苦加班，完成了一项任务，很出彩，领导不给奖金怎么办？年轻的兄弟成长很快，但是人力决定只给他加薪5%怎么办？带团队跟打仗一样，没有真金白银谁会长期跟你卖命，必须能搞到钱；

所以，情商不高，没有两把刷子，这些事一件也搞不好。

至于会不会写代码，反而没有那么重要，就我的经验来看，大多数时候授权放手比自己事必躬亲好的多，仗着自己经验多，天天指点江山反而会招来很多人反感。