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

2020-11-20 From 程序之心 By 丁仪

前些年,有人说程序员只能干到 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 岁后的职业规划

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

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

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

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

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

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

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

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

掌握软件系统方法论

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

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

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

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

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

形成自己的方法论

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

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

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

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

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

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

本文来源:程序之心,转载请注明出处!

本文地址:https://chengxuzhixin.com/blog/article/200056.html

君子曰:学不可以已。
《算法导论(原书第3版)》
本书是操作系统领域的经典教材,主要内容包括进程与线程、内存管理、文件系统、输入/输出、死锁、虚拟化和云、多处理机系统、安全,以及关于UNIX、Linux、Android和Windows的实例研究等。第4版对知识点进行了全面更新,反映了当代操作系统的发展与动向。本书适合作为高等院校计算机专业的操作系统课程教材,也适合相关技术人员参考。
发表感想

© 2016 - 2022 chengxuzhixin.com All Rights Reserved.

浙ICP备2021034854号-1    浙公网安备 33011002016107号