我在一家著名的软件咨询公司工作，有一天，公司决定对开发人员的个人绩效进行度量。
这个目标很美好：评估个人能力，帮助开发人员成长。
指标经过层层分解，来到我们团队，经过经理的认真讨论，决定不使用代码行数和Bug数这样的指标，因为它们太容易被玩坏了。
那用什么呢？用Story Point(用户故事点数)。
这是一个敏捷软件管理和开发中的一个度量单位，用于估计实现一个用户故事的复杂度。
因为用户故事代表了给用户带来的商业价值，所以记录下每个开发人员实现了哪些用户故事，评估他们的绩效是很合理的。
我们使用Jira，每个人都可以把自己的名字和用户故事关联，从而认领一个用户故事，并且统计每个人的生产率也超级方便。
很快，经理就在统计报表中发现了一个最糟糕的程序员，Tim。
Tim这个人的“得分”（用户故事点数）一直为0！
他的得分并不是从高到底降下来的，而是一直保持着0的记录。
很明显，绩效低下的Tim必须得走人。
经理让我安排人去接手Tim的工作，但是我坚决拒绝了。
Tim的“分数”一直为零，是因为他从来没有认领过任何的用户故事！
相反，他的工作方式非常独特，他把他的时间都花在了和别人进行结对编程上。
对于经验不足的开发人员，Tim会让他们充当结对编程中的导航者角色，帮助他们来找到解决方案，Tim不会嘲弄，压迫这些新手，而是采用苏格拉底的启发式来引导他们，给他们带来顿悟时刻。
和有经验的开发人员结对时，编程就是充满争吵的共同创造，用不同的视角来解决问题，创造出比单个人能想象的更好的东西。
Tim是一个出色的程序员，和他结对你总能学到新的东西。
所以Tim的名下没有交付任何用户故事，但是他交付了一个团队，这个团队变得更加高效，有生产力，更加卓越，更加有趣。
这一切，都是因为Tim在团队中。
我向经理解释了Tim的情况，邀请他时不时到团队来看一看。
每当经理出现的，他都能看到Tim和不同的程序员坐在一起，帮助这些程序员完成他们的事情。
你可以肯定，代码质量在显著变好，开发时间在显著缩短。
是的，更好，更快，并且更加省钱。
最后，我们留下了Tim，并且悄悄地干掉了衡量个人生产力的指标，取而代之的是衡量团队的绩效，即我们这个高效的团队能给整个组织带来什么价值。
后记：这篇文章在Reddit和HackerNews上引发了激烈的讨论，我这里摘录几个：
Luke22_36：编程行业还没有完全接受这样一个事实：编写软件是一项创造性工作，虽然有很多的技术性，但仍然是一门艺术。然而，我们看到的管理方法更像是生产可重复产品的工厂，而不是艺术工作室。
Stratoscope：大约 20 年前，我在一家中等规模的软件公司工作，该公司销售 Mac 和 Windows 桌面应用程序。
该团队主要拥有丰富的Mac 经验，但是刚刚接触 Windows，所以Windows版本自然也存在一些问题。
当时，我被称为“Windows专家”，因此他们聘请我来帮助改进软件的Windows版本，并帮助团队熟悉Windows编程。
我经常把一天的时间花在“上门拜访”上：去其他开发人员的办公室，结对编程，fix bug，或者只是谈论 Windows API 的最佳实践等。（是的，我们都有私人办公室！）
几个月后，我收到了一条绩效平庸的评价：“你的生产力并没有达到我们所希望的水平，特别是在团队其他成员生产力提高的情况下。”
James: 这让我想起贝尔实验室的一件轶事，有人想计算出谁是最有生产力的员工（根据获得的专利等信息），发现他们中的许多人会与同一个人共进午餐。
这个人的工作效率并不高，但他总是会提出深思熟虑、引人注目的问题，从而使他的同事的工作效率明显提高。
对于Tim的故事，你怎么看呢？
原文链接：
https://dannorth.net/2023/09/02/the-worst-programmer/