[译] 小心负产出的开发者

人们很容易高估提前一个月上线的收益，而低估了这之后擦一年屁股的成本。

原文：Beware of Developers Who Do Negative Work

在每个程序员的职业生涯中，都遇到过负产出的开发者。负产出的概念可能听上去有点怪，一个人什么都不做可以零产出，但是怎么会有负产出？

举个例子，我以前就共事过一个很糟糕的开发者，他任期六个月里提交了两次代码修改，这两处修改功能不正常并且搞坏了产品中的其他功能，他的第三次提交撤销了这两次修改的代码。

听上去他的产出是零。然而有好几个开发者碰到了他这些代码的报错，他们需要追查是自己的代码产生了问题还是其他人的，他们需要和他讨论修复这个问题的细节，他们也参与了最终判定这段代码不值得修复，最好的解决方案是删掉。

最终整个团队浪费了十几个小时在这件事情上，这个开发者没有产出并且，降低了其他开发者的生产率。

这种例子我还能举出来很多。

我遇到过很多开发者写出来能工作的代码……但是太过复杂需要其他开发者花大量时间才能搞明白。当然，理解其他人的代码总是要花一点时间，但代码容易理解的程度还是有显著区别的。

我们来简单算一下这里面的成本：

糟糕的开发者花 5 个小时写了一段错综复杂的代码，团队中另外四个开发者搞明白这段代码各花了 10 小时。

净支出：(4 * 10) + 5 = 45 小时成本

好的开发者花 10 个小时写一段简明易懂的代码，团队中另外四个开发者理解它只需要每个人 1 小时。

净支出：(4 * 1) + 10 = 14 小时成本

差别：45 - 14 = 31 小时。

这些数字还会呈几何级地增长。我见过特别糟糕的代码导致一个优秀的开发人员也要花两周时间去完成一个合理情况下两个小时就能搞定的任务。事实上两个小时也是宽松的了，如果一开始那部分代码就有良好的设计实现，完成任务只需要 30 分钟。

负产出还有种更糟糕的情况是一个开发者固守着过时的编程经验并且在公司里有相当大的影响力。这种开发者憎恶新东西或者改变工作习惯，他们滥用影响力以保持自己不需要接受新事物，结果就是团队中的其他开发者受到负面影响。

我曾经在一个公司工作，有段时间大家在探索整合多个开发者工作的新方式。旧方法每次要花费数小时时间，当时我们每周要进行两次。我们已经确信新方法可以把每次的时间花费减少到几分钟，然而当时有个资深开发者不喜欢这个改变并且他有权否决相关进展。我们花了六个月时间才绕过他把方案推进完成。

4 小时 x 每周 2 次 x 26 周 = 6 个月时间里浪费了 208 小时

唉……这相当于一个人工作五周的时间。

你能想象什么都不干么连续五周么？如果这些时间完全从你的生命中浪费掉？

幸好这 208 个小时分摊在很多程序员身上，但依然是个糟糕的事情。这只是那个公司里发生的事情之一，导致这个事情的原因同样导致了其他很多事情，产生了大量内耗。

这也牵出了负产出开发者导致的人力成本。大部分人都希望在工作中获得成就感，他们希望自己的时间花在有价值的事情上，对开发者而言就是希望交付有价值的软件产品，浪费时间对此是有伤害的。我们大部分都希望和有才能的人共事，对团队造成负担的人会打击士气，他们是我们成功的障碍，也让我们觉得工作的价值受挫。

开发者在市场上的供不应求使得他们非常容易解决这个问题：换个工作好了。这显然不是公司希望看到的结果。

如果负产出开发者带来的成本如此高昂，他们是怎么得到聘用的？部分可以解释为面试流程需要改进，但不那么受关注的另一部分是降低招聘标准的动机。

公司往往在某个时期会有大量的工作要短时间内完成，公司内的开发人员不够完成目标的时候就需要招聘更多开发者。因为当今的招聘市场是卖方市场，程序员有议价优势而公司则需要花相当一些时间来做甄别。这就是降低招聘标准的动机来源。当工作量涌来的时候，一些人就开始慌忙招聘。他们觉得办公室里有更多的人口总能完成更多的工作。

然而事实远不是这样。并非所有的开发者都能给团队带来正面价值。我理解紧张的时间表带来的压力，但仓促招聘并不是这个问题的解决之道，而总是会让问题变得更糟。不好的开发者不仅拖慢你的计划，还会挤走公司里的优秀开发者，最终公司的进度会比完全不招一个人更慢。