程序员的成长阶梯和级别定义(转)

近月，公司召开了今年的「武林大会」—— 年度晋升评比。如今大会落幕，尘埃落定，我呢既作为评委又作为选手参加了这次大会，有些感想在这里简单写下。

随着公司发展壮大，研发人员数量也日趋庞大（6k+），每个人如何成长，发展，修炼，打怪升级不仅是自身不可回避的命题，也是公司的一个重要命题。在互联网这行以 BAT 为首逐步发展出了自身成熟并成型的技术人员晋升体系和级别定义。例如：B 厂从 T1 到 T10，A 厂从 P1 到 P11，T 厂分四个大级别(T1 ~ T4)每个大级别内部再细分若干小级别。但不管如何划分，我感觉从自身的成长过程来回顾，总体还是能分出几个有明显界线的阶段。

初级

刚入职场的新人一般都在这个级别了。这一点倒是不区分本科还是硕士，比如我第一家公司硕士毕业进去算初级工程师，本科是助理工程师。而公司对于刚毕业的同学的级别定义也是类似，本科 T1-1，硕士 T1-2。大级别都是 T1，小级别上的细分区分可能也就是在薪酬起点上略有不同（别问我差多少，我也不知道，但估计差距不大）。遥想当年刚毕业那会儿参加校园宣讲，T 厂来学校宣讲，本科年薪是 6万，硕士 8 万，博士 10 万，而当时华为统一给硕士比本科每月高一千，我估摸现在的相对差距应该也差不多这样吧。

仅仅从年收入差距来看读硕读博是个很不划算的选择，而恰恰很多人选择读硕就是为了能有一个更好的工作选择，而选择的标准也还恰恰就是薪酬占据主导方面，这貌似就是一个误区啊。当然你也可以为了学术梦想去读，但我估摸这样的人千中无一吧。去年看了期《奇葩说》，一个清华男从本科读到博士，跑去节目上说了半天就是为找什么工作而苦恼，惹得同为清华出生的矮大紧同学当场发飙。而同为点评嘉宾的蔡康永说了句是实在话：

一直花时间求学，也许是为了拖延人生做决定的时间。

说了那么多其实就是无论本科还是硕士，作为程序员初入职场都是新手，要从最基本的学起做起，比如：学习并熟悉公司常用的开发技术、涉及的工具和框架，熟悉公司的开发流程规范等等。也许博士会稍有不同，但可能也要取决于所处的领域和学术成就是否刚好处在业界的风口上，比如最近随着 AlphaGo 不断升温的 AI 领域。

中级

要说中级和初级最本质的区分是什么，我觉得体现在独立性方面。初级的同学刚进公司，一般还会给安排一对一的导师帮助其快速上手，所以很多初级的同学在工作上就对导师存在依赖性。而工作一段时间（1、2年吧）后，他们对公司的各种开发流程规范已经相当熟悉，熟悉其参与项目中的部分业务、产品和代码，能够按要求完成业务功能开发。

所以中级的工程师基本能够独立承担开发工作，甚至有些还能指导新人了，成长为公司「动作执行」层面的中坚力量。这个层面的基本要求就是：完成动作、达成品质、优化效率。 但观察下来这个级别的工程师多数都能做到完成，但品质可能有瑕疵，效率上甚至可能有缺陷。而关于效率和品质总是在不断的迭代和改进中去不断完善的，自身也在这个过程不断成长向着下一个阶梯迈进。

而不少人卡在这一阶段，就是因为虽然不断的在完成工作，但却没有去反思，沉淀，迭代并改进，导致一直停留在了不断的重复中。

高级

这个级别基本属于能独立负责某个小项目或大项目中的子系统或模块，自己是项目的骨干成员，属于团队或项目中最大的个人贡献者。

相比于中级，高级工程师在「动作执行」层面属于攻坚力量，不仅能独立完成高级难度的开发任务，而且在用户体验（品质提升）和性能优化（优化效率）都能作更全面的考量。不仅对开发任务完成的又快又好而且还能能清晰的定义出多快多好。比如，一个服务的响应时间 99.9% 的响应是 20 毫秒内，内存消耗估计不超过 1G，并发吞吐每秒 10000，类似能用清晰的数据来定义服务品质和效率。

资深

这个级别有些叫「资深工程师」，有些叫「架构师」，而不同的叫法代表了两种不同的发展方向。在基础研发、算法或特定技术复杂领域会向「资深工程师」方向发展，属于深度优先。而在面向业务开发的领域，业务复杂度高于技术复杂度，则会向「架构师」方向发展，属于广度优先。

不管是深度还是广度，进入这个级级说明在特定领域都已经具备了相当的积累，在项目和团队中担任技术骨干。除了自身专业知识、技能和实践经验的积累，还能够从中总结沉淀出有效的方法论，引导和组织团队成员一起进行推广应用。积极主动的输出自身经验，为跨团队项目提供技术支持。

很多工作有一定年头的高级工程师卡在迈入这个级别的门槛边，我觉得有两个原因，一方面是自身虽然各种实战经验丰富，但却没有系统的去梳理自己多年的积累，未能很好的形成体系。所谓体系也这就是上面所说的沉淀出有效的方法论，有效方法论的最大作用是帮助快速决策，而且决策的正确概率还会比较高。另一方面，就是其虽胸有块垒，腹藏千言却倒不出来，出现明显的瓶颈效应，造成的负面作用就是很难对其「资深」的程度作出有效评定。

专家

技术专家一般在公司领衔重大技术项目，而且在其细分的技术领域，于业界也有公认的影响力。以「家」冠名会让人感觉遥不可及，高不可攀。实际「家」也分大小，一般的「大家」实际都是稀世珍宝，举国稀有的，确实是遥不可及，但也有「小家」相对来说就没那么遥远。

而专家总和影响力挂钩，影响力听起来很虚，那换个相对实的角度说说影响力。作为一个 Java 程序员，在学习使用 Java 的过程中总有那么几个人，你不仅要去读他们的书还要去看并且使用他们写的代码，在 Java 这个领域你总是绕不过去。那么这就是他们在这个领域实实在在的影响力，自然也是这个领域的专家。所以，专家可能就是这个领域内你绕不过去的人吧。

评定

有了级别的定义，那么如何来评定一个人到底属于怎样的级别呢？这点在低级别的评定中标准会相对宽松，而越往高级别走越难评定。对于不同级别的评定标准一些大公司（如：T 厂）都定义了覆盖多个维度的评判标准，并给出了详尽的说明。对于高阶的晋升会由公司专家评审小组来组织晋升述职答辩，评审小组的评委就是根据这些多维度的标准来做出一个综合的评判。

这里多维度的标准是客观的，而评委的评判则是主观的。这就好像奥运比赛中类似跳水这样的项目，有规定的动作、组别和技术难度系数，这些都是客观标准，这对于运动员的完成情况的评判会有一些共识的判断，但细微之处就偏主观了。如果郭晶晶和一个新秀一起参加国际大赛，她们跳同样的难度同样的组别动作，完成的同样好，但最后可能郭晶晶会得分高一点，我印象中有届奥运会上就出现过，这就是人主观评判的细微之处。

而实际在一场半小时的述职中评定一个程序员的级别要比给一次跳水打分难多了，而且准确性更低。正如前文所说很多「高级」的工程师虽然已经在特定领域进行了多年的沉淀积累，但这也只是第一层次：深度理解并掌握了某领域的知识和技能。下一层次则是能很好的表达和展示该领域的知识和技能并能让人容易听懂，如果做到这层的话，基本就大幅降低对你进行评定的门槛和难度。而再进一步若你对该领域的观点和认识不仅能让人听懂还能给人启发，并让人认同和被二次分享，那么你自然就具有了很多组织里对高阶人才要求的专业影响力。而在从积累沉淀中提炼观点和认识并分享的过程中，又会反过来加深你对该领域的认知，甚至还能帮助发现盲点，不断形成正向反馈的循环。

爬楼

职业的发展就像爬楼，每一个级别就像一个楼层。鲁迅曾在《故乡》里说：

其实地上本没有路，走的人多了，也便成了路。

所以，前面定义出来的阶梯不过就是很多人已经走过的路，我们只需要去沿着这条路去持续成长就能爬上还算不低的楼层。只是到了一定楼层后我们会发现上面似乎还有几层但却看不见下一层的楼梯了。因为再往上走的人就不多了，也就没能成了路，自然也就看不见，这可能就是很多大公司中到了一定层次面临的困境。

程序员这行处在科技与互联网的日新月异之下，所以不管你之前积累了多少但也停不下来。一旦停下来了，你这洼水可能就变成了一塘死水，死水终有干涸的一天。走完看得见的路后，就该走看不见的路了，这条路谁也定义不了，只能自己去试。从这里开始每一步都是一个不同的选择，而每一种选择都影响着未来人生的不同路径。

...

最后，看到这里你，行路的脚步是否迈得更坚定点了呢？最最后，是我写这篇文章时参阅过的一些类似主题文章，有兴趣可以看看。

参考

[1]. 虎嗅. 深挖BAT内部级别和薪资待遇. 2015.05
[2]. TimYang. 程序员晋升攻略. 2015.10
[3] 梁宁. 腾讯的职级系统——看清自己的职场宿命. 2014.08

http://www.cnblogs.com/mindwind/p/5453059.html