我所认识的“最差”程序员

2023年9月2日 4 分钟

衡量 developer productivity 最棒的一点是，你可以快速识别出“差劲”的程序员。我想跟你讲讲我所认识的“最差”程序员，以及我为什么努力把他留在团队里。

几年前，我在 Twitter/X 上写了一篇关于我所认识的最好的程序员的帖子，我应该把它整理成一篇博客文章。现在，我觉得也应该跟你说说我所认识的“最差”程序员。他的名字是 Tim Mackinnon，我想让你知道他有多么可以被衡量的不productive。

当时，我们为一家著名的软件咨询公司在一家大型银行工作。银行决定引入个人绩效指标，“用于评估和个人发展”。这一决定层层下达，最终落实到我们团队的 story point 交付上。此前，部门经理经过深思熟虑，因为他知道你不应该衡量诸如代码行数或发现的 bug 数之类的东西，因为人们很容易在这方面作弊。

Source: http://dilbert.com/strip/1995-11-13 Source:http://dilbert.com/strip/1995-11-13

取而代之的是，我们将衡量交付的 story，或者可能是 story point (事实证明这无关紧要)，因为这些代表了业务价值。我们使用类似 Jira 的工具，人们会在 story 上署名，这使得生成这些 productivity metrics 变得非常容易。

这就引出了 Tim。Tim 的得分始终为零。零！不仅仅是低，或者呈下降趋势，而是字面意义上的零。一周又一周，迭代又迭代。Tim 的得分为零。

很明显，Tim 必须离开。这是经理的结论，他要求我做出必要的安排，将 Tim 替换为实际交付 story 的人。

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

你看，Tim 的 productivity 得分为零的原因是，他从未认领任何 story。相反，他会花一整天的时间与不同的队友进行 pairing。对于经验不足的 developers，他会耐心地让他们主导，同时引导他们找到解决方案。他不会打断或强加于他们，而是让他们花时间学习，同时精心设计富有洞察力和学习的时刻，通常以 Socratic questions、what ifs、how elses 的形式。

对于资深人士来说，这更像是共同创造或切磋；将不同的世界观应用于问题，以产生比我们任何一个人独自思考更好的结果。Tim 是一个很棒的程序员，你总能从与他 pairing 中学到一些东西。

Tim 没有交付软件；Tim 交付的是一个交付软件的团队。整个团队变得更有效率、更有成效、更加协调、更加规范、更加有趣，因为 Tim 在团队中。

我向经理解释了所有这些，并邀请他不时来观察我们工作。每当他过来时，他都会看到 Tim 与不同的人坐在一起，处理“他们的”事情，你可以肯定的是，该事情的质量会明显提高，并且 value 的实现时间会明显缩短——是的，你可以同时拥有更好、更快和更便宜，这只需要自律——而不是 Tim 没有与人 pairing 的时候。

最终，我们留住了 Tim，并悄悄地放弃了个人 productivity metrics，转而支持团队问责制，我们追踪并庆祝作为一个高效团队为组织带来的业务影响。

tl;dr

请务必衡量 productivity ——我完全赞成问责制——最好是以节省、产生或保护的美元表示的有形业务影响。这通常很难，所以使用代理业务指标也可以。

只是不要试图衡量复杂自适应系统中一个单元的个人贡献，因为这个问题的前提是有缺陷的。

例如，DORA metrics 关注的是工作系统如何运作，无论是作为 Westrum 文化指标还是技术变更流入生产的过程。它们衡量的是引擎，而不是单个活塞的贡献，因为这毫无意义。

此外，如果您有机会与 Tim Mackinnon 共事，您应该抓住这个机会。