Stephen Tobolowsky在定义联体三角形……

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

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

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

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

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

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

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

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

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

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

· 有15年以上编程经验

· 有2年编程经验并且有非常好的学习能力

· 有1年使用一个非常热门的框架的经验，并且框架发布时间要超过一年

· 一本技术书的作者

· 可以在白板上默写出来某个计算机科学的算法

· 写过一个开源库并且在公司里用起来了

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

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

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

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

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

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

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

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

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

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

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

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

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

加上问责

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

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

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

始于责任

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

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

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

· 公司很小，所以每个人都要肩负多种责任，承担多种角色，并且要从头到尾的跟进解决问题。在我们这台机器上没有居中的传动齿轮。

· 我们依赖并打造内部社区的力量，以及我们参与的外部社区，尤其是开源界。

· 我们在技术目标和代码可维护性可用性上追求极致。

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

- 可以为队友及客户提供清晰专业的技术和项目指导。

- 在内部和更大的编程社区里可以辅导他人、教授并且做出贡献。

- 可以很愉快的将软件交接给用户或者接手维护它的其他程序员。

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

联体三角形：简单的解释

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

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

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

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

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

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

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

文氏图：更复杂的解释

在上文中我们已经把对资历的评估方法提升到了更高境界：“这个人需要多少指导？这个