为什么程序员到一定年纪开始关注管理相关的内容，不再在技术上深入下去？

空白派

为什么程序员到一定年纪开始关注管理相关的内容，不再在技术上深入下去？
原文地址：https://www.zhihu.com/question/485901214

检验医师

一个程序员Coding到了技术专家的级别，不是因为他想要奔着“管理者”的定位去发展，而是因为“技术专家”本身的定义，就包含了管理能力。作为一名技术专家，就意味着你除了有很强的技术能力、业务能力，还需要有战略的视角，有向外看的洞察，有很好的整体架构思路和商业变现的思维（当然也可能意味着又土又秃又有钱….
说白了，从“大头兵”升任“管理者”，意味着你开始“享受”驾驭复杂性的快感。


一位优秀的RD，技术专精能力发展到了一定阶段，你会发现，老板对你委以重任的事情越来越多，刚开始会让你管三四个人的小团队（大头兵阶段），如果胜任，你会被委任担纲更大的团队Leader，你的工作方式，也从串行到并行。
做RD的那会，你每天要做的事情不多，线性流程、循序渐进就可以，做完这个再做那个。但当上Leader后，几乎所有工作都必须是并行的了，很多事情平行推进，多线程、多任务的管理，考验很大。
作为新手Leader，刚开始你可能会经常顾此失彼、按下葫芦浮起瓢，捡了芝麻漏掉西瓜，或者以为它是西瓜，但发现那个芝麻也很重要，诸如此类，经常出现狼狈不堪、灰心丧气的情况（别问我为啥知道）。


之前管的人少时，你很多时候不需要说话，一个眼神或者哼哼一声或者打个手势比划一下，对方就能明白是什么意思，就可以贯彻执行。但后来团队的人越来越多，有很多新人加入，有刚入行的菜鸟，也有经验非常丰富的人，甚至他们身上会带有上一家公司原本的职业痕迹和工作习惯。怎么把这个团队建设好，是非常大的一个难题。


原先做程序员的时候，你光脚的不怕穿鞋的，真的是挣一分钱就多一分钱，挣十块钱就多十块钱，按质按量完成OKR，隔一两年有个晋升加薪，就没事偷着乐了。但做了Leader，你每天要想的更多的是怎么做判断，不让一次判断错误，拖累其他做对的事情。你做的事情体量越大，你的判断失误所导致的风险也越大，甚至可能会把部门和公司之前辛辛苦苦挣来的那点钱全给搭进去，多少人多少年的心血可能一夜之间就没了。作为一个管理者，你每天需要解决的可能都是这种错配的问题。
随着管理岗位的上升，慢慢你发现，工作中会遇到越来越多的一些不可逆、不可预测、涌现和突变的事件，这就意味着复杂性。比如在某一个尺度上不相关的因素，某天你会发现，它竟然在另一个尺度上就会变得具有决定性作用。
如果有一天你能轻松驾驭这种复杂性，所谓实现“人生的自由”也就不那么难了，包括财务的自由、人身的自由（想想那些科技公司大佬们…）。
世界上有三样东西是掩饰不住的：咳嗽、喷嚏和真正的实力。所以，程序员到了35+的年纪，不是不想在技术上深入，而是技术能力发展到一定程度后，成为管理者是专业能力发展的一个自然结果之一。
成为管理者意味着你有着更好的行业洞察力、逻辑分析能力、抽象力和判断力，也就是驾驭复杂问题的能力。
但说到底，一个人的职业发展，是很私人的一件事情，取决于你想成为什么样的人，希望过什么样的生活，你内心渴望的是什么，做什么事情会觉得很爽。所以没有一种路线是适合所有人的，但成为管理者，毫无疑问是程序员更通用的职业发展路线（去看看科技大厂的工程师发展能力地图就知道）。
一个大牛，自己当然可以一直CODING，比如做个人开发者。但个人的力量再强大都是有限，更多的难题是需要团队的力量。如果你喜欢别人用“技术牛人”，“技术专家”来指代你，那么成为管理者至少是一个不太费劲的佐证和标签。

大力水手

不一定要懂管理，但一定要理解人类组织行为和加以利用。道理很简单，因为技术深入到一定程度之后规模必须要扩大，把技术做出来的人力成本会超越你一个人有生之年的所有时间，唯一的办法就是找更多人帮你一起做同一件事情。至于别人为什么要跟你做事情，而不是自己做自己的事情，这就是你要解决的问题了，也就成了你技术继续深入的子问题。
做技术有两个极端的角度。一个是最大化技术产出的生产力，然后最大化生产力带来的利润。这个角度是必然会导致规模扩大的，因为技术投入和生产力产出之间存在一个性价比最高点，超过了之后继续投入技术只会导致单位性价比下降，因此大家不会这样做。那要继续最大化利润，就只能停留在性价比最高点上扩大规模了。这是业界所有对股东负责任的企业在做的事情。
不喜欢这个角度？出门左拐一路走到底。学院科研是另外一个角度，不在乎利润最大化，伸手向政府、向基金会、向捐赠者要钱，一心想要把技术做下去。这种看起来「免费」的科研经费往往跟企业利润不在一个量级，也就不可能进行同等规模的投入和产出。在计算机领域，往往科研比落地超前 20 到 30 年，也就是说现在研究出来的东西还需要至少 20 年才能大规模地转化为生产力、有效提高人类生活水平。
你想要把自己锁小黑屋里一个人做科研，成果在你退休后甚至死后才对人类产生影响，还是想要把早已存在的技术拿来商业落地规模化赚大钱？想好了就不要反悔。
那些独自一人通过纯粹科技创新成为霸道总裁的，都是韩剧男主角一样的存在，在现实世界中是找不到的。

感恩由您

大多数的科技公司其实并不是技术驱动的，而是业务驱动的。程序员在这些公司里的职责是用技术方法解决商业问题。
规模小一些的公司里，程序员用技术来实现基本的产品，比如网站前后端、移动端应用等等。这些技术非常成熟，解决方案很丰富，某种意义上来说“没什么技术含量”。这类公司里需要的程序员主要是熟练运用某种特定的技术、框架、库去把产品从无到有做出来。
中等规模的公司里，需要用技术解决的问题主要是可扩展性，就是如何让系统支持更多的用户，更大的数据量等等，并且同时要提高稳定性、可靠性、安全性等等。这就是很多面试喜欢问的高并发问题的来源。这类问题虽然技术上比实现业务逻辑要更有挑战，但是依然有足够多的方案可供选择。换句话说，这些问题并不是全新的，已经有人解决过。这类公司的程序员需要做的是针对当前公司的技术和业务架构对各种方案进行适当的裁剪和改良。
只有到了规模大到一定程度以后，才会遇到前所未有的技术问题。也只有到这个规模的公司，才有资源（钱）去养一些真正的技术大佬，让他们去解决更加高级的技术问题。即便如此，最终的目的还是为了获得更大的商业利益。
<hr/>从个人职业发展的角度来说，深耕技术当然是一条可行的道路，但是风险比较大。人的精力有限，能深耕的技术领域不会太多。比如一个数据库专家不太可能同时也是一个前端技术专家。深耕一个领域的风险是，一种技术（或者领域）随着时代的发展变得不再流行的时候，就需要重新花时间去学习另一个领域。
但是管理某种意义上是一种“通用的”技术。虽然管理具体的业务或技术团队需要一些特定的知识，但是总体上管理团队的方法是通用的。从这个角度来说，从技术转向管理可以视为是一种去风险的方法。

继续前进

随着年龄的增长，遇到的和需要解决的问题也越来越大，越来越难。
问题数量的增加，只会增加工作量。
而问题难度规模的增长，则需要能力的增长。
技术固然是一种能力，但是别忘了管理也是一种能力。
当问题规模和难度到一定水平之后，就不能仅靠技术来解决了，管理手段也是解决问题的方法之一。
比如，当软件的规模很大，包含几百万行甚至上千万行代码的时候，需要数百人的团队去协作开发。这就不能仅靠高明的算法，优秀的架构，严谨的接口定义去解决。大团队协作需要管理。
工程师本质是解决问题的人，问题不仅限于技术问题，解决问题的手段也不仅限于技术手段。

队长是我

你以为的技术：
1、SQL分库分表
2、使用分布式消息队列
3、用云主机替代实体机
4、用Vue、React、Angular替代jQuery

实际的技术：
1、制定LLVM IR语法规则，并实现LLVM和Clang，并带动一整套工具链的进化
2、改进渲染算法，让渲染效果更逼真（Unreal Engine）
3、通过改进传输算法，在同等条件下实现传输速率提升40%以上（mTCP）
4、研发下一代通讯算法的理论，并实现（5G技术、6G技术）
5、把关系型数据库带入分布式事务时代（OceanBase）

你说，你不做管理，还能做啥？

以目前从业者的普遍状态而言，能正确设计一套缓存更新回写机制的，应该不超过10%，估计还是高估了。

=========更==========
看来冒犯了一批人，但我也是码农。。。。
我的意思是，因为大家做的事情，说到本质，都是堆业务，并没有什么非你不可的技术。
JVM把一大票能写出内存不泄露的C++工程师的价值给干没了，Electron的出现把一大票精通桌面技术的工程师的价值给干没了。个人价值被剥离出来，都积攒在“平台”上。

屠龙少年闭关10年练就一身屠龙绝技，出关后发现，龙早就没了，只能在摆摊坎猪肉。

在这个论点上，把精力花在管理上，必然收益更大。既然谁干都差不多，那决定怎么干，必然成为价值的积攒点。
当然了，做技术管理，也不是一个说说就行的那么简单的事儿。对于工程而言，抛开需求本身的合理性和可行性不谈，最重要的就是技术选型和实施方案制定。这就是问题中所描述的“管理”。