在软件开发者的职业生涯中，我们一定会遇上一两个产生负价值的同事。你也许会想：负价值是个什么鬼？ 曾经就有过这样一个同事。在 6 个月的时间里，他对代码库进行了两次更改。而这些更改不但没有起到好的效果，反而影响了产品的多个其他功能。这样的开发者，他做的事情不仅没有任何效果，还会影响其他人的工作，这就是他们所产生的负价值。为了解决他所带来的问题，整个团队都不得不花费很长时间来解决问题。

在软件开发者的职业生涯中，我们一定会遇上一两个产生负价值的同事。你也许会想：负价值是个什么鬼？ 

曾经就有过这样一个同事。在 6 个月的时间里，他对代码库进行了两次更改。而这些更改不但没有起到好的效果，反而影响了产品的多个其他功能。

这样的开发者，他做的事情不仅没有任何效果，还会影响其他人的工作，这就是他们所产生的负价值。为了解决他所带来的问题，整个团队都不得不花费很长时间来解决问题。

相信你一定也遇到过这样的“坑队友”。

还有一种开发者，他们写的代码都能正常工作，但是他们写的代码却只有自己能看懂，团队中的其他人要想看懂他写的代码，要花费大量的时间去理解。这样的开发者，在某种程度上也是在贡献负价值。

我们来算一笔账：

• 糟糕的开发者花费 5 个小时，写了一堆难以理解的代码。其他 4 名开发者为了看懂这些代码，每个人都花费了 10 个小时：

• 总花费时间： (4 * 10) + 5 = 40 + 5 = 45 小时

• 而好的开发者，可能花费 10 个小时写了清晰明了的代码，其他 4 名开发者只需要 1 个小时就能完全搞懂：

• 总花费时间：(4 * 1) + 10 = 4 + 10 = 14 小时

• 可节省时间： 45 - 14 = 31 小时 

而且这些数字还有可能会大量增长。我曾经见过这样一个情况：由于代码写的太糟糕，一名优秀的开发者花了两周的时间才搞懂这部门代码；如果这部分代码写的清晰明了的话，这名开发者只需要 2 个小时就能搞懂。

还有一种情况，也是最可怕的情况，那就是这些负价值开发者不愿意学习新的东西，而且他还是团队中的领导。由于不喜欢新东西，他会一直使用过时的代码编写方法，而且要求团队中的其他人要向他看齐。结果就是，整个团队中的每一个人都成为了负价值开发者。

我就有过类似的经历，我以前供职的公司中，本来所有人都在使用一种代码编写方式，这种编写方式每解决一个问题需要我们花费数个小时的时间。后来，有一个同事向我们介绍了一种新的方法，新方法解决问题只需要几分钟。但是，团队中那个做决策的资深开发者却不让我们使用这个新方法，因为他不喜欢改变。

大多数人在工作的时候，都希望能有一些成就感，我们希望感到自己的时间没有被浪费。对于开发者来说，最大的成就感就是做出有价值的软件。

我们也希望能和有才能的人一起共事。而如果团队中有一个这样的“拖油瓶”，开发者会感到非常不舒服。

对于开发者个人来说，如果团队中真的有这样一个负价值开发者，这个问题也很好解决：换个工作，毕竟市场对于开发者的需求程度很高。但是对于企业来说，这绝对是一个灾难。

那么话说回来，这些负价值开发者当初是如何找到工作的？一部分原因，是企业的面试流程设计的不够完善。还有一部分原因，那就是企业总是在不知不觉的降低自己的雇佣标准。

有的时候，企业会发现自己有大量的工作要做，而且时间紧迫，而公司内的开发者数量不够。在这种时候，企业最容易降低自己的招聘标准。

某些企业在这种情况下，就会进行“恐慌招聘”。可惜的是，并不是所有开发者都能给团队带来正面价值。我理解企业在用人方面的急迫性，但是恐慌招聘无法解决问题。坏的开发者不仅会拖慢你的速度，还会让那些优秀的开发者离开你的团队。

原    文：Beware of Developers Who Do Negative Work
译    文：SDK.cn
作    者：鲁行云（编译）