工作中，碰到一些这样的例子，总有人提出疑问，为什么一个同事工作勤勉，完成了很多事情，季度绩效评定很高，但晋升却碰壁了。之前已经写过一篇《技术晋升的评定与博弈》，基本就能解答这个问题。但隐藏在背后的更深层次的本质却是：工作、学习与绩效的关系。 工作 程序员的主要工作是：编程，产出代码，完成需求，交付软件系统。 程序员按其工作技能和经验，大体又分为三个阶段：初、中、高级。三个级别的程序员的主要工作都是编程与产出代码，产出代码的数量也许相差不大，但产出代码的属性可能有明显差别。 在曾经的文章中提出过一个代码属性：资产与负债。由大量初级程序员产出的代码并以此构建的软件系统，如果最终能完成交付，那么很可能资产和负债性基本持平。这是很多早期创业公司的特点，因为缺乏资金和足够的知名度，难以吸引到又多又好的中高级程序员加入。这样的系统多属于勉强满足业务需要，看不出明显的 bug，但一遇到特殊情况就容易宕机。整个系统虽然勉强能支撑公司运营，但其中欠下了大量的技术债，先活下来，未来再来慢慢还。 若是完成了一个债务比资产还大的系统，会是个什么样的情况呢？那这就是一个还存在明显 bug 的系统，是基本无法完成交付和上线的。因此，现在主流都是先完成一个资产和负债刚好过平衡点的系统，发布上线，接受反馈，再快速迭代，在迭代中不断地提升其资产性，降低其负债性。在 Facebook 的著名标语激励下，奋力前行：Done is better than perfect（比完美更重要的是先完成）。 而中高级相比初级程序员，就不仅仅是交付代码，完成工作，还有后续的两条：达成品质、优化效率。从初级向后两级跨越的门槛就在于此，比较容易被卡在不断地在完成工作，但却没有去反思，沉淀，迭代并改进，导致一直停留在了不断的重复中。 程序员的工作，以产出代码为主，从初级到高级，代码的负债属性逐步降低，资产属性不断提升，并成为高品质的个人贡献者。在这个层面上，还是 Facebook 的另一条标语足以说明问题：Code wins arguments（代码赢得争论）。 学习 学习，是唯一能让你突破不断循环怪圈的不二法门。 程序员在攀登职场阶梯的道路上，走过了高级，后面会有好些分叉路线。比如，转到脱离技术的纯管理岗或者技术管理岗。我以前写过，技术主管或架构师某种意义上都属于技术管理岗，不懂技术是做不了这两个角色的。或者继续沿着深度领域走，成为细分领域专家。 这后面哪条路适合你呢？你是随大流，还是自己真得认真思考过？这是做选择题。如果一生要工作三十多年，前十年你多在做解答题，解决一个又一个问题。那么在大约走过三分之一后，你就会开始做越来越多的选择题。为什么呢？因为一开始可能都没有太多选择的机会。而做好选择题，就需要大量的学习，还需要不断的试错。 面对怎么选路的问题，我近年学习的收获是这样的：选择走最适合实现个人价值的路。这就是我的基础选择价值观。程序员的个人价值该怎么实现？该如何最大化？程序员作为个人贡献者，产出的增长随时间和经验实际上连线性都不是，而是呈对数曲线的（《两种增长曲线》）。到了一定时间必然面临瓶颈，这就需要找到一个价值贡献放大器。有人很幸运的编写服务于数千万或数亿人的软件服务，这是产品自带的价值放大器。这样同样写一份代码，你的价值就是要比别人大很多。而转管理者、主管或架构师，这些角色无非都是自带杠杆因子的，所以也有价值放大作用。但个人能否适应得了这样的角色转换，又是另一回事了。 现在稍具规模的中大型公司内部的职场阶梯模型，我看基本都源自拉姆·查兰的那本书《领导梯队》。书里把人才潜能分成三种：熟练潜能、成长潜能、转型潜能。原书文中对这三点做了详细的特征描述（比较长），我简单提炼下主要特点：
人力资源管理中的高潜人才盘点，基本就来自这套模型，主要就是识别出这三类潜能人才。「熟练潜能」就是对学习的最低要求，在程序员这个技术日新月异的行业里，维持现有技能确实已经让不少人感觉很竭力了。 攀登的这条阶梯，它从来不是笔直的。在每一个拐弯处，都应减速、思考、学习、进步。学习也常与错误相伴，查理·芒格说过： 世界上不存在不犯错误的学习或行事方式，只是我们可以通过学习，比其他人少犯一些错误 —— 也能够在犯了错误之后，更快地纠正错误。但既要过上富足的生活又不犯很多错误是不可能的。实际上，生活之所以如此，是为了让你们能够处理错误。 绩效 绩效，特别是程序员的绩效，从来都是个谜（《程序员的绩效之谜》）。 一谈绩效，管理者就会说谁谁绩效很好，你看加了很多班，做了很多事。之前说了程序员交付的软件系统，如果说代码的资产和负债属性相当，大家可能会没有直观感觉。做个大家熟悉的类比，如果只是相当，这就像我们刷信用卡购买了一项产品或服务，满足了当下的需求，赢得了时间，但将来这笔欠款是要还的，不还就会付出代价。但如果是资产远大于负债，那就是刷了卡，后面却不用还了的感觉，那应该是种暗爽的感觉。后者才叫绩效好，但如何评估？谜。 最近看刘润的文章讲到 KPI 管理，提到了一个考核微软技术支持的办法。感觉挺有意思，如果把它换成程序员的场景可能就是这样一些关键指标：
其中 A 难度系数基于团队共识达成，因为大量的业务需求，其实很多难度近似。B 和 D 实际是两个互相制衡的因素，本来用 1 小时完成的，你自己记录成 10 分钟，那么完成的总的数量就会变少。C 展现了代码技术能力，完成同样功能的代码，资产性不变，越少的代码行数越少负债。这样当衡量有效工作产出（E）时，同样的 E，A 和 D 大的技术能力更好。 当然，这是一个简化的理想模型，但现实中程序员的考核恐怕比这个模型更简单粗暴。但它也指出了一个事实：晋升技术能力更好的人，他们解决更难的问题因而创造壁垒，产出更多的资产和更少的负债。而对于仅仅单一高绩效的人，不适合用晋升来激励，而应该用奖金来奖励。 ... 为什么业界喜欢三到五年的程序员？按一万小时理论，三到五年接近或满足了这个量的编程训练，这个阶段就是产出代码的黄金时段，量大质优，而且各公司的“坑”（职位）也多。 稿源：瞬息之间 |
