如果你的公司稍微有一点规模，你一定听说过一个质量部门。简单来说就是降本增效。接下来，一起看看这个规则上“最糟糕”的程序员

...

测量开发人员的生产力的伟大之处在于你可以迅速识别出糟糕的程序员。我想告诉你我所认识的最差的程序员，以及为什么我努力让他留在团队中。

几年前，我曾在Twitter/X上写过一篇关于我所认识的最优秀程序员的帖子，我应该将其写成一篇博客文章。现在，我觉得公平的是也告诉你关于最差的程序员。他的名字叫Tim Mackinnon，我想让你知道他的生产力是可度量的低下的。

我当时在一家知名的软件咨询公司工作，为一家大银行提供服务，这家银行决定引入个人绩效指标，以“用于评估和个人发展目的”。这一决策经过了部门经理的深思熟虑，他知道不能衡量诸如代码行数或发现的错误之类的东西，因为人们可以轻易操纵这些指标。

相反，我们将衡量已完成的用户故事数量，或者可能是故事点数（事实证明这并不重要），因为这些代表了业务价值。我们使用类似Jira的工具，人们会在故事旁边写上自己的名字，这样生成这些生产力指标非常容易。

这就引出了Tim。Tim的分数一直都是零。零！不仅是低，也不是下降趋势，而是真正的零。周复一周，迭代复一迭代。Tim的得分一直是零。

好吧，Tim显然必须离开。这是经理的结论，他要求我采取必要的措施将Tim移除，并由一个实际交付用户故事的人取代他。

但我坚决拒绝了。对我来说，这甚至不是一个艰难的决定，我只是说不。

...

你知道，Tim的生产力分数为零的原因是他从未承担过任何故事。相反，他会整天与不同的团队成员合作。对于经验较少的开发人员，他会耐心地让他们驾驶，同时引导他们朝着解决方案的方向前进。他不会干扰他们或强迫他们，而是让他们花时间学习，同时精心制造洞察力和学习的时刻，通常是通过苏格拉底式的问题、假设、其他方式来进行的。

对于经验丰富的开发人员，更像是共同创作或较量；将不同的世界观应用于问题，以产生比任何一个人自己想到的更好的解决方案。Tim是一个出色的程序员，与他合作时，你总是能学到东西。

Tim不是在交付软件；Tim正在交付一个能够交付软件的团队。整个团队变得更加高效、更有生产力、更加一致、更加习惯、更有趣，因为有Tim在团队中。

我向经理解释了所有这些，并邀请他不时过来观察我们的工作。每当他过来时，他都会看到Tim与不同的人一起工作，致力于“他们”的事情，你可以肯定，那件事的质量会显著提高，交付价值的时间会显著缩短——是的，你可以既更好又更快又更便宜，只需要纪律——而当Tim没有与人合作时，情况完全不同。

最终，我们保留了Tim，并悄悄地放弃了个人生产力指标，改为追踪和庆祝我们作为一个高绩效团队为组织带来的业务影响，这是团队的责任。

尽管要衡量生产力是一种很好的做法——我完全支持责任制——最好的方式是以以节省、创造或保护的美元表达的具体业务影响来衡量。通常这很难，所以代理业务指标也是可以接受的。

但不要尝试衡量复杂自适应系统中单位的个人贡献，因为这个问题的前提是错误的。

例如，DORA指标是关于工作系统的工作方式的，无论是Westrum文化指标还是技术变更流入生产中的情况。它们衡量的是引擎，而不是个别活塞的贡献，因为这毫无意义。

此外，如果你有机会与Tim Mackinnon一起工作，那么你会怎么做？

原文链接：

https://dannorth.net/2023/09/02/the-worst-programmer/