[譯] 當心負產出的開發者

人們很容易高估提早一個月上線的收益，而低估了這以後擦一年屁股的成本。

原文：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 個小時分攤在不少程序員身上，但依然是個糟糕的事情。這只是那個公司裏發生的事情之一，致使這個事情的緣由一樣致使了其餘不少事情，產生了大量內耗。

這也牽出了負產出開發者致使的人力成本。大部分人都但願在工做中得到成就感，他們但願本身的時間花在有價值的事情上，對開發者而言就是但願交付有價值的軟件產品，浪費時間對此是有傷害的。咱們大部分都但願和有才能的人共事，對團隊形成負擔的人會打擊士氣，他們是咱們成功的障礙，也讓咱們以爲工做的價值受挫。

開發者在市場上的供不該求使得他們很是容易解決這個問題：換個工做好了。這顯然不是公司但願看到的結果。

若是負產出開發者帶來的成本如此高昂，他們是怎麼獲得聘用的？部分能夠解釋爲面試流程須要改進，但不那麼受關注的另外一部分是下降招聘標準的動機。

公司每每在某個時期會有大量的工做要短期內完成，公司內的開發人員不夠完成目標的時候就須要招聘更多開發者。由於當今的招聘市場是賣方市場，程序員有議價優點而公司則須要花至關一些時間來作甄別。這就是下降招聘標準的動機來源。當工做量涌來的時候，一些人就開始慌忙招聘。他們以爲辦公室裏有更多的人口總能完成更多的工做。

然而事實遠不是這樣。並不是全部的開發者都能給團隊帶來正面價值。我理解緊張的時間表帶來的壓力，但倉促招聘並非這個問題的解決之道，而老是會讓問題變得更糟。很差的開發者不只拖慢你的計劃，還會擠走公司裏的優秀開發者，最終公司的進度會比徹底不招一我的更慢。