怎样才能叫高级程序员？

Stephen Tobolowsky在定义联体三角形

“我真的开始对我在这里做的事情感觉不自信了。如果我们都不知道高级程序员到底是个什么样子，那我又该怎么朝这个目标努力？”

我们Frontside公司是习惯于每周二下午开个全公司例会的，会上大家谈谈上周取得的成绩，并为下一周订订计划。

在最近一次会议上，我们谈到了最近要招一位高级程序员，大家一谈到这个话题就都立刻激情爆发了。因为要提到对公司影响重大的事，非招聘新人加入团队莫属了，所以很自然的大家就开始各抒己见，热烈地讨论起我们要找的人到底应该具有什么样的资质来。

可是除了依靠直觉，一屋子的人里却没有一个能够把大家的想法归纳起来，到底要怎样才能叫做“高级”。

当一位同事说出了文章开始我引用的那段话之后，我意识到我们已经迷迷糊糊地碰上了一个对于整个公司来说都非常重要的问题：我们无法为我们想招聘的角色下一个定义，也不知道我们该怎样培养我们的程序员。

定义“高级程序员”的难题

就我个人来说，我是对“高级程序员”这个称号非常怀疑的，尤其因为当初在我有了9个月的正规编程经验，他们就为了给我涨工资而给了我这个称号之后。

事实上，如果你找来两个有经验的程序员，让他们分别描述一下他们心中的“高级”是个什么样子，我敢保证他们的答案会大相径庭。

“怎样才能叫高级程高序员”这个问题其实非常依赖于语境，而且弹性空间非常大，以致于在我们这个行业里各个公司都可以给出任何自己需要的答案。

下面是一些身边人给出的我亲眼见到的关于“高级程序员”的定义：

• 有15年以上编程经验
• 有2年编程经验并且有非常好的学习能力
• 有1年使用一个非常热门的框架的经验，并且框架发布时间要超过一年
• 一本技术书的作者
• 可以在白板上默写出来某个计算机科学的算法
• 写过一个开源库并且在公司里用起来了

这些定义之间相差实在太远了。但想想在我们的生活中，很多东西都是没法下定义的，那又有什么问题呢？

为什么要费力下这个定义？凭直觉做判断不好吗？

当大家在会议上说出这个困惑时，大家实际上说的是我们并没有非常清晰和可定义的标准来雇佣人、开除人和提拔人这个问题。大家说的对，事实上也就是这么混乱。

更糟的是，我们的核心使命——培养程序员——完不成了，因为我们没办法帮他们设定出一条发展路线来。

“我一见到这个人我就知道他是个高级程序员”——这种说法揭示了另一个重大问题：“高级程序员”已经根深蒂固地成了一个偏见的有效载体。

把“高级程序员”作为供奉偏见的一种方法

当我们描述一个高级程序员应有的样子时，我们都是根据自己的经验和喜好来的，这就意味着这个词已经有了非常强的主观色彩。

当我们没有明确具体的标准，只能凭着直觉来判断一个人的资历的时候，我们就没有办法不带有偏见，但我们还是要做出判断。当一个人同时申请几份开发工作的时候，非常有可能有的公司认为他只是初级，有的会认为他是中级，还有的却认为他是高级，当然大家都不会直说自己是怎么判断的。

作为招聘经理，当我们做出判断的时候我们都会自认为非常正确，即使大家得到的结论相距甚远。

这样的结果就是不断被加强的偏见会阻止一些人进步，最终导致“头衔通货膨胀”。在当今技术界，各种偏见都不可避免的偏向白种男人，那么这种凭直觉做判断的体系就更多的会伤害女士和有色人种。

为什么大家还没有解决这个问题？

首先给这个问题下定义就很难，因为它和工作环境的具体情况关系太大了。大多数公司领导人处理这个问题的办法都是走着瞧，而最终解决方案也都是“差不多”就行了。

解决这个问题也没有什么动力，因为当定下明确标准之后，公司领导人靠直觉做决定的权力很大程度上就会被剥夺了，而且还要为做出的决定负责。有谁会主动做一件让自己又要让出权力又要背上责任的事呢？

加上问责

我喜欢被问责，我也非常习惯。我懂得在为某件事负责任的同时，实际上我的自由度也是非常高的。就是否雇佣某个人这个问题来说，凭直觉下的决定往往比依据清晰的标准做出的决定更容易让人后悔。因为我们的直觉太容易受影响了，从我早上是不是忘了吃早餐，到那个人是不是能即兴谈起某个动画片，都有可能。

问责也为我们打开了改进之门。作为招聘经理，我的责任是打造一支有战斗力、快乐和能力互补的团队。要不断改进并且朝着这样的目标努力，可以靠直觉，可以全凭运气，但我们也可以创建一种先定义、再衡量、又问责反思然后再从头开始这样的循环，来保证我们通向最终目标。

问责可以帮助我们在通向未来的道路上完成从乘客到驾驶员的角色转换。

始于责任

现在问题变成了：我们怎样才能创造一种用于衡量资历的可度量的标准，而不是用那些有明显缺陷、象玩游戏一样的方法？

我能想到唯一相对公平的评判一个侯选人的方式就是问几个关键问题：这个人的责任是什么？他是怎么完成任务的？他工作上需要什么样的帮助？

我们先从定义我们的情况开始了。当我们总结了Frontside的工作环境特征后，事情就开始变得清晰：

• 公司很小，所以每个人都要肩负多种责任，承担多种角色，并且要从头到尾的跟进解决问题。在我们这台机器上没有居中的传动齿轮。
• 我们依赖并打造内部社区的力量，以及我们参与的外部社区，尤其是开源界。
• 我们在技术目标和代码可维护性可用性上追求极致。

于是团队成员的责任就非容易确定了：

- 可以为队友及客户提供清晰专业的技术和项目指导。
- 在内部和更大的编程社区里可以辅导他人、教授并且做出贡献。
- 可以很愉快的将软件交接给用户或者接手维护它的其他程序员。

所有这些责任构成了我们评估资历的标准基础。

联体三角形：简单的解释

我恰好最近有机会与好几家不同规模公司的负责人讨论了“高级”的定义，大家意见的共同点只有一个。

大家最简单的关于资历的共同解释就是：这个人需要多少指导？这个人能给别人提供多少指导？

我赞成这个“高级程序员的组合三角形”是一个不错的主意，可以简明的表达出内在含义，就象Action Jack的“成功的组合三角形”一样。

但即使这样的标准也是非常容易引入偏见的。它缺少一些重要的标准，并且过度强调了口碑这类容易见到的东西，以及解释深奥的计算机术语的能力。

在会上我们讨论出了一个新的框架

会上的热烈讨论有了一个非常酷的结果。在我试图灌输上面的三角形理论时，另一位员工提出了一个崭新的心理模形，吸引了大家的注意力。

她把我们在Frontside确定资历的方法描绘成了一个文氏图（用闭合的区域表示集合的图示法）。三个集合分别是：这个人有多强的独立工作能力及领导力？这个人技术实力如何？这个人和外部环境关系如何、有多大贡献？

文氏图：更复杂的解释

在上文中我们已经把对资历的评估方法提升到了更高境界：“这个人需要多少指导？这个人可以给其他人提供多少指导？”但正像我们的员工指出来的，如果到此为止的话，还会有非常多令人困惑的地方。

那我们该怎样定义一位候选人到底能把他的本职工作做得多好？我们怎样能把评判标准引向一些具体的方面，而千万不要变成数学公式？

我们最终按照候选人要做的事总结出了三方面：技术能力、领导力和交际能力，并细化提炼出了12个特质。我将在下一篇文章中详细阐述这12个特质，但现在我可以简单说说。

三大方面

技术能力（Technical capability）：技术能力强的人通常都对技术有浓厚兴趣，他们会不断钻研决不放弃，最终会做出可供经验不足的工程师使用、维护和学习的解决方案。

领导力（Leadership）：有领导力的人知道怎样为自己及别人发展并保持一种目的感。他们会指出公司里及自己职业生涯中出现的问题，并且揽到自己身上最终解决掉。

交际能力（Community/Connectedness）：交际能力强的人非常希望自己成为一个大集体中的一员，有非常强的奉献意识，身上有别人（同事、客户等）无法轻易描述的个人魅力，并且存在感非常强，生活充实快乐。

“对文化的适应能力”怎么样

我们最初差点把交际能力叫做“对文化的适应能力”了，但我非常怀疑这个定义实际上是个扼杀思想的陈词滥调。“对文化的适应能力”就是一个万金油，所有你想在程序员身上见到的可你又说不出来的东西都可以用它往上套，而且这里面也非常容易藏入偏见。

当我们定义好了可以让Frontside的文化一致的标准之后，上面的观点就定义成了交际能力。

在三个不同方面衡量资质

还记得那三个方面吗？技术能力、领导力和交际能力，每个方面都有自己的从初级到高级的发展路线。

现在人们换职业都不是什么新鲜事了。很容易见到那些有很强领导力和交际能力但刚参加完代码训练营的人，他们的技术水平就只能被认为是一般。相反，一个经验丰富又受过正规培训的技术人员却有可能缺乏领导力和交际能力。

很少有人真的能在三方面都能达到高级水平，事实上也很少有人真的想在三方面都成为高级。我们Frontside把资质定义为这些方面的混合体，并努力帮助人们在他们想提高的方面获得进步。

证据：唯一能得到的衡量依据

衡量每个方面的资质都需要证据。如果你已经做了一些工作，那你手上应该已经有了一些证据。

我们将在下一篇文章中讨论这12个特质，每一个都有详细的标准，可以让候选人提供证据来说明他们经过时间的积累的确具有这些特质并且经验丰富。

但总的来说，如果在某个方面有一两项特别擅长和精通的特质的话，就可以认为他在那个方面是高级了。

比方说，假如某个人告诉你他的代码用好几种语言实现过，那在“技术好奇心”这个特质上就可以得高分了。如果他还会非常严谨的为项目的核心代码写出全面、高质量的测试用例并用于持续集成，你就差不多可以认为他在技术能力上达到了高级水平。

或者如果某个人经常辅导别人、组织聚会，或者会做一些让大家过得更轻松的事，那我们就差不多可以在交际能力这方面给他打高分。

如果某个人曾经带过几个团队，那他就应该已经掌握了带团队的技巧。再加上挖掘问题根本原因的能力，那你就可以认为他在领导力的方向上达到高级了。

我们怎么定义“高级”

我们的衡量标准是如果某个人在技术能力上达到高级水平，他在领导力或交际能力中有一方面也能达到高级水平，我们就认为他是高级程序员了。如果他还想继续提高剩下的一方面，我们愿意提供帮助。

如果他是在领导力和交际能力都能达到高级水平，在技术方面能属于中高级的话，我们也认为是高级程序员。

举个一年前发生过的真实例子，我们雇佣了一个初级程序员，因为据我们评估，起码在最初的六个月中他需要非常多的指导。

到了第六个月，他的技术水平就已经达到中级了。到第一年结束时他就已经达到了高级水平。我敢这么说的原因是我们知道如果他离职，我们需要雇佣一个高级程序员来顶替他。

这样的事情为什么能发生？因为他是在我们公司起步的，而当时他已经在交际能力和领导力方面都可以达到高级水平了。所以他要在我们团队中做高级程序员的工作只是需要提高技术能力而已。

只看技术水平并不够

对于技术水平高但在领导力和交际能力方面都缺乏经验的人，不能直说“在我们这里你达不到高级程序员的标准”，这话太刺耳了。但对于他在团队中能承担的责任来说，我们可以暂时评订为中级，等他把另一方面或者两方面都提高了之后，我们再把他提升为高级。

很多公司只根据技术水平来做判断，但这样对于我们这种小型的而且非常依赖合作模式工作的公司来说行不通。其实我非常担心那些只衡量技术能力的公司是认可“孤独的天才开发者”这样的危险想法的，觉得一个人技术水平高，就想当然的认为领导力和交际能力也很好。

在大公司中每个人都只负责一小部分工作，我非常乐于见到他们分享对于“高级程序员”的定义，那应该会在技术和非技术的方面都更加全面，让我们工作得效率更高，尤其是在需要与客户打交道的团队里。

成为高级需要多久？

“高级程序员”是不是就意味着“若干年的经验”？事实上我并没有看到过哪个人不用五年就可以成为高级程序员的。要在很短的时间内就把一些特质发展得非常好来在某一方面达到高级水平其实是非常困难、甚至不可能的，更别说在多个方面全部成为高级了。

而且“五年经验”并不一定要意味着“五年的软件开发经验”。如果一个人已经在领导力和（或）交际能力上满足了条件，那他只需要提升技术能力，就已经可以发挥高级程序员的作用了。

我们招聘的“秘密武器”很大程度上源于我们观察到的事实：对于具有领导力和交际能力的人来说，要再提升技术能力并不需要很多时间，反之则不然。我见过很多这样的人，从代码集训营中出来两三年后就已经成了非常好的高级程序员。

更多要讨论的

这篇文章留下了非常多未能回答的问题。我们在这三个方面是用什么具体方法来评估候选人的能力和特质的？在面试前和面试中该怎么衡量呢？该如何把这些评估结果与一些具体的东西联系起来，比如工资？

这个框架又如何应用于非高级程序员？程序员们该什么时候升级？怎么升级？初级、中级和高级之间的区别是什么？它们之间差了些什么？这些词会不会实际上毫无意义而该被替换掉？

最后，如果真的可以的话，这个框架该如何应用于其他与Frontside有着非常大的文化和需求差异的公司？

在下一篇文章中我们会详细回答这些问题。

告别直觉

定义“高级”是一个仍在进行中的而且出乎人意料困难的过程，但我们还是要做这件事，因为它对我们非常重要。如果不能给“高级程序员”下一个清晰的定义，我们就迷失了培养员工的方向，就没有具体的办法来衡量要加入我们团队的人，也没有办法让员工相信我们可以信赖，更没办法来改进流程。

这个行业已经应该告别“我一见到这个人我就知道他是个高级程序员”这样下结论的年代了，我们该向着一些我们可以定义和分享的东西努力。让我们一起把开源的思路带到我们雇佣和发展员工上吧。

希望我能在下一篇文章中把留下的主要问题都解释清楚。如果你对文中内容有问题或者不同想法，你可以在Twitter（@tehviking）上找我，或者更好的方式是，你也把你的想法写出来，我会在我的文章里链接过去。

英文原文：The Conjoined Triangles of Senior-Level Development