在軟件開發者的職業生涯中，我們一定會遇上一兩個產生負價值的同事。你也許會想：負價值是個什么鬼？

曾經就有過這樣一個同事。在 6 個月的時間里，他對代碼庫進行了兩次更改。而這些更改不但沒有起到好的效果，反而影響了產品的多個其他功能。

這樣的開發者，他做的事情不僅沒有任何效果，還會影響其他人的工作，這就是他們所產生的負價值。為了解決他所帶來的問題，整個團隊都不得不花費很長時間來解決問題。

相信你一定也遇到過這樣的“坑隊友”。

還有一種開發者，他們寫的代碼都能正常工作，但是他們寫的代碼卻只有自己能看懂，團隊中的其他人要想看懂他寫的代碼，要花費大量的時間去理解。這樣的開發者，在某種程度上也是在貢獻負價值。

我們來算一筆賬：

糟糕的開發者花費 5 個小時，寫了一堆難以理解的代碼。其他 4 名開發者為了看懂這些代碼，每個人都花費了 10 個小時：

總花費時間： （4 * 10） + 5 = 40 + 5 = 45 小時

而好的開發者，可能花費 10 個小時寫了清晰明了的代碼，其他 4 名開發者只需要 1 個小時就能完全搞懂：

總花費時間：（4 * 1） + 10 = 4 + 10 = 14 小時

可節省時間： 45 – 14 = 31 小時

而且這些數字還有可能會大量增長。我曾經見過這樣一個情況：由于代碼寫的太糟糕，一名優秀的開發者花了兩周的時間才搞懂這部門代碼；如果這部分代碼寫的清晰明了的話，這名開發者只需要 2 個小時就能搞懂。

還有一種情況，也是最可怕的情況，那就是這些負價值開發者不愿意學習新的東西，而且他還是團隊中的領導。由于不喜歡新東西，他會一直使用過時的代碼編寫方法，而且要求團隊中的其他人要向他看齊。結果就是，整個團隊中的每一個人都成為了負價值開發者。

我就有過類似的經歷，我以前供職的公司中，本來所有人都在使用一種代碼編寫方式，這種編寫方式每解決一個問題需要我們花費數個小時的時間。后來，有一個同事向我們介紹了一種新的方法，新方法解決問題只需要幾分鐘。但是，團隊中那個做決策的資深開發者卻不讓我們使用這個新方法，因為他不喜歡改變。

大多數人在工作的時候，都希望能有一些成就感，我們希望感到自己的時間沒有被浪費。對于開發者來說，最大的成就感就是做出有價值的軟件。

我們也希望能和有才能的人一起共事。而如果團隊中有一個這樣的“拖油瓶”，開發者會感到非常不舒服。

對于開發者個人來說，如果團隊中真的有這樣一個負價值開發者，這個問題也很好解決：換個工作，畢竟市場對于開發者的需求程度很高。但是對于企業來說，這絕對是一個災難。

那么話說回來，這些負價值開發者當初是如何找到工作的？一部分原因，是企業的面試流程設計的不夠完善。還有一部分原因，那就是企業總是在不知不覺的降低自己的雇傭標準。

有的時候，企業會發現自己有大量的工作要做，而且時間緊迫，而公司內的開發者數量不夠。在這種時候，企業最容易降低自己的招聘標準。

某些企業在這種情況下，就會進行“恐慌招聘”。可惜的是，并不是所有開發者都能給團隊帶來正面價值。我理解企業在用人方面的急迫性，但是恐慌招聘無法解決問題。糟糕的開發者不僅會拖慢你的速度，還會讓那些優秀的開發者離開你的團隊。