程序员是青春饭吗？30岁后的发展方向和突破

前些年，有人说程序员只能干到 30，后来大家把年龄提到 35，最近好像又有提到 40 的迹象。最近 Python 创始人 Guido 入职微软了。Guido 在 1989 年创造了 Python，无论从哪个角度看，都是绝对的高龄程序员了。

很多人都说写代码最多到 35 岁，妥妥的青春饭，然而科学分析不这么认为。《Is Programming Knowledge Related to Age?》论文对 1694981 名 StackOverflow 用户的研究发现，程序员的平均年龄是 30.3 岁，其中数据清洗后参与分析的用户是 84248 名程序员，平均年龄 29.02 岁。

在年龄分布中，人数最多的是 25 岁，中位数是 29 岁。然而分析发现，程序员的能力从 25 岁左右开始上升，一直到 50 岁后才会开始下降。论文还研究了程序员对新技术的跟进，发现不同年龄的程序员对新技术的学习并没有差太多。大龄程序员对某些新技术的学习甚至超过年轻程序员。所以论文得出的结论是，程序员的技术能力上升可以到 50 - 60 岁，并且大龄程序员跟进新技术的能力和年轻程序员相差不多。

从身边的观察发现，30 岁的程序员积累了大量经验，可能才刚刚成为优秀的人才，架构设计能力、领导力需要大量的实践积累，不是能够轻松掌握的。互联网是一个新兴行业，大部分从业者都是后期加入的，平均年龄要低于其他行业。

一个程序员在 30 岁后，可能面临技术专家、技术 Leader、架构师三个发展方向的选择。

技术专家很好理解，在一个领域深耕，对业务和代码都有很好深刻的理解，经验丰富，能够用技术解决公司遇到的实际问题。成为技术专家需要大量的实践积累，正常发展情况下差不多都要到 30 岁左右。正常来说，技术专家是人才梯队中非常重要的角色，对技术方案设计有很大影响。

前几天看到有个公众号转载一篇高并发的文章，一个看起来一年内工作经验的作者展示了漏洞百出的技术方案，还能发上线，可见技术专家对团队的重要作用。没有技术专家的团队，人才梯队很难建立起来，团队内成员的成长可能也会受影响。

技术 Leader 会开始涉及技术管理方面的事务。注意这里是 Leader，不是 Manager。Manager 是管理者，而 Leader 更多是领导者。作为技术 Leader，需要重点保障核心业务、做技术建设、提升业务效果。为团队设定合理的目标，做好排兵布阵，协调各个团队和资源。所以业内往往称为“技术管理”而不是“管理”。

技术 Leader 比团队其他同学视野更开阔，对长远的发展趋势看的更准，有技术前瞻性。虽然已经成为团队中最牛逼的程序员之一，但是也要逐渐学会借他人之手写代码，专注于写代码的时间比以前减少很多，而这一点正是优秀程序员转变为技术 Leader 所面临的最大挑战之一。

架构师是一个非常出名的称谓了，然而却很少有专门的架构师岗位。阿里前几年有架构师岗位，不过现在也回归“技术专家”这样的纯技术岗位了。架构师必须是最出色的程序员，拥有技术深度和广度，有系统性的认知和技术前瞻性。

架构师通常和技术 Leader 有部分重叠，尤其是在团队规模比较小的时候，两者往往是同一个人。随着软件规模的增大，架构师开始在比技术 Leader 更高的高度上看待问题，这时候架构师和技术 Leader 开始分化为不同的人。架构师也不一定是公司任命的权威领导者，但是在团队内部通常有非权威领导力，是团队内部非常信任的技术领导者。

这三个发展方向可能会有重叠，对个人来说，还是最好想清楚侧重点是什么。

越是到职业发展的后期，越不能依靠代码本身。所有人都使用着同样的开发语言，掌握着同样的语法和脚本。作为执行者很难体现出优势，总不能说掌握的语法和二方包比别人多吧。优秀的程序员能比别人写出更好的代码，主要还是在如何写代码，以及代码背后的思考，也就是程序员的方法论。

方法论英文单词是 methodology，也就是说它是关于方法(method)的学问，是关于人们认识世界、改造世界的方法的理论，是人们用什么样的方式、方法来观察事物和处理问题。简单地说，方法论是成熟的思维方式。

成熟的方法论有很多。前面文章提到的黄金圈法则，是思考问题、分析问题的方法论。领域驱动设计是架构设计方面的方法论，能够帮助解决复杂问题。金字塔原理，是思考问题、解决问题、写作、PPT 演示方面的方法论。系统化思维，是对复杂系统如何观察和分析的理论，也能指导设计复杂系统。

我们常说的“抓手”、“赋能”、“共建”、“打法”、“对焦”等看起来比较虚的东西，其实就出自于方法论，是方法论中对具体事物和行为背后的客观规律的总结。脉脉上很多人对此嗤之以鼻，成为了大家吐槽的对象，但是这都是很成熟的概念。

如果长期停留在使用框架的层面，容易陷入工具误区，把使用框架当做技术，思维方式也被局限在框架里。会有一种技术很牛逼的错觉，但是和其他人相比，却没有多少优势，容易被更年轻更有活力的后辈取代。

方法论的形成需要长期的积累，可以借鉴学习圈理论。学习过程由具体经验、反思观察、抽象概括、主动实验四个阶段，并形成一个闭环。首先学习一个具体的东西，然后停下来对自己的经历进行复盘和思考，再对学习的内容进行抽象，概括成为真正能理解、能吸收的知识，最后再把学习的概念和理论应用于实践并解决现实的问题，如此往复循环。

定向钻研一个技术方向，可以加深技术深度，有助于形成方法论。比如，可以定一个目标，让需求上线的时间缩减一半或者同样成本支撑的需求数量翻倍。接下来就需要思考什么样的架构设计能够支撑翻倍的效能，很多情况下都会走向配置化、提升复用、热部署等，接下来你就可以总结出你的方法论了。

亲自设计一个框架，也是一个不错的选择。既能在纵向深挖，又会有横向拓展的机会。不过这样的尝试一定要以足够的经验积累为前提，否则可能走入误区。跳出日常的习惯，拔高视野，很快就会有领悟，甚至推翻低层次的认知。

复盘和反思有助于改造认知，实现认知升级。推荐使用黑匣子思维，记录下过程中的思考和问题，能够帮助更好地复盘。关于复盘的方法，推荐阅读《复盘:对过去的事情做思维演练》，书中讲了很多复盘的方法和技巧，是关于复盘的方法论。

经过思考和训练，你会得到很多经验和认知，会形成自己的思维方式，能够对一类问题形成体系化的深度思考，然后再总结出一些概念进行抽象，使经验适用于更广阔的共性问题，就实现了经验到理论的升华。把自己的理论应用于实践，观察实际效果，对比之前的预期，再领悟新的经验和思考，循环往复，就形成了方法论。

以上就是本文的全部内容了，与君共勉。

— 【 THE END 】—
本公众号全部博文已整理成一个目录，请在公众号里回复「m」获取！

3T技术资源大放送！包括但不限于：Java、C/C++，Linux，Python，大数据，人工智能等等。在公众号内回复「1024」，即可免费获取！！