程序員不是砌磚工人，他們是做家

　　英文原文：Your Developers Aren’t Bricklayers, They’re Writers

若是你有 10 個程序員，最好的那個可能至少比最差的那個好 5 倍。這絕對不是胡扯。

咱們這樣定義「更好」：工做速度更快，產生的 bug 更少，代碼更具可讀性、邏輯性和可維護性。

程序員不是砌磚工人，但他們每每被當成是砌磚工人。 （我並非說歧視這些職業）

「爲何我須要高級程序員，要知道一樣的薪酬我能夠僱兩個初級的了？」

「這個功能一個程序員作須要三個月的時間，那就只須要再加兩個，就能夠在一個月內搞定了。」

　　爲何說上面的想法很荒謬？由於咱們沒有一種簡單又有效的方法來衡量程序員的生產力。一旦碰到咱們沒法衡量的東西，咱們就會忽略它。

　　我這樣問你好了：你是願意讓兩個新手來照顧你的寶寶，維修你的車，給你作腰椎穿刺，仍是寧願找一個資深的？

相關研究代表，最好程序員的生產力最高可比最差程序員的高 28 倍。可是用在這些最好程序員身上的成本確定不會有這麼多，因此他們是軟件領域中最划算的「特價商品」。

ROBERT GLASS，《FACTS AND FALLACIES OF SOFTWARE ENGINEERING》

　　若是你必定要比較的話，那麼其實程序員更像是做家。

　　有些做家寫出的東西能數以百萬計地賣出去，而有些做家寫出來的東西無聊至極最後只能用來燒火用！

　　可是，他們都生產出了一本書，所以，他們都是做家。但是除非你去閱讀他們的書，不然你就不會知道他們倆的差異。

編程經理老早就認識到好程序員和差程序員二者的生產力有着天囊之別。但實際測得的數據結果依然讓咱們全部人都大吃一驚。在研究中，Sackman、 Erickson 和 Grant 想要衡量一組經驗豐富的程序員的表現。結果代表，最佳和最差的生產力比例平均約爲 10：1，特別是編程速度的比例使人吃驚地達到5：1！

FRED BROOKS，《THE MYTHICAL MAN-MONTH》

　　下面我給你講一個真實的故事。（有關名字已做更改。）

　　一家軟件公司須要在他們的標誌產品中實現一個新的模塊。Mr Lousy（差先生）恰好有空，因而就將這個任務交給了他，讓他立馬開工！

　　通過四個月的修修補補，差先生終於完成了。 QA 團隊發現存在着大量的 bug 和矛盾之處，並將報告返回給差先生。差先生根據報告又花了 2 周的時間來修復這些 bug，並最終給出了一個新的版本！那些該死的惱人 bug 真是絞盡了差先生的腦汁。

　　測試而後修復，如此循環了兩三次。

　　用戶已經在期待這個新的模塊。銷售人員也簽署了一些新的客戶。把這個模塊作出來，並整合到下一版本中這一過程的壓力之大可想而知。可是，所幸，成功了！開香檳慶祝吧！

　　呀，不對，新模塊中依然盡是 bug。羣衆的眼睛老是雪亮的，客戶老是特別擅長於找到一些之前從未被發現的 bug。因而他們聯繫技術支持。技術支持團隊再去找是什麼地方出了錯，是客戶不知道如何操做功能，仍是他們本身搞錯了，抑或這只是一個 bug，一個能夠重現的 bug。…… 而後技術支持團隊提交了錯誤報告。因而，差先生悲劇了，——個人意思是，哪怕他正在搞另外一個項目，在這個時候也只能放下手頭的一切工做來解決這些麻煩事。

　　（這尚未涉及到代碼的維護性，邏輯性和文檔化問題——由於之後確定會有其餘人來改進這些代碼）

　　可是，唉，怎麼說呢……彷佛有一些 bug 超出了差先生的能力範圍，他根本修復不了。此外，不斷出現的新 bug，沒人知道確實它們是新出來的，仍是之前就有但就是沒有被發現而已的。技術支持煩不勝煩。而銷售愈來愈惱火，由於新客戶紛紛表示這個模塊太不靠譜 了，他們要取消合同！

　　最後，老闆不得不讓 Mr Rockstar（好先生）來看一看這些代碼。

　　好先生並不想爲差先生收拾爛攤子，不少結構在他眼中都是沒有意義的。他建議重寫代碼，預期大概須要一個月的時間。而後他開工了，只比原先估計的 多了幾天就完成了模塊（他是好先生，而不是完美先生）。除了 QA 團隊發現了一些小錯誤，一切都能如期工做。 QA 團隊在內心默默擔憂：若是全部的程序員都像他同樣，那他們就沒有用武之地了。差先生認爲好先生這是在傲慢地嘲笑他，但他的見解對好先生而言是可有可無的。

　　改進過的模塊很快發佈了。每一個人都很高興，由於終於能夠正常工做了。萬歲！

　　如今真的到了能夠開香檳慶祝的時候了！

　　可是此時，彷佛全部人都忘記了好先生只用了一個月左右的時間就成功搞定了差先生用了七八個月也搞不定的任務。

　　這兩個開發人員生產力水平的巨大差別因而可知一斑——他們執行的是徹底相同的任務。

經過編寫更精簡但功能更多的代碼，經過編寫 bug 更少更易於維護的代碼，一個優秀的開發人員能夠減輕 QA 人員，同事和管理人員的工做壓力，提升身邊每個人的生產力。這就是爲何研究得出的這些數據，如 28 倍的生產效率是可能的，甚至可能還報低了，若是你縱覽全局的話。

PHIL HAACK，《10 DEVELOPERS FOR THE PRICE OF ONE》

　　那麼，在這個故事中可能會發生的最糟糕的事情是什麼呢？

　　好先生終於注意到他比差先生的效率要高得多：他能輕易識別不良代碼。可是儘管如此，他很確定本身的薪資和差先生的差很少。他表示不滿，甚至於毅然決然地離開。因而你的開發團隊失去了一個高效的力量支柱。

　　即便他不離開，當面對因爲發佈/項目延遲致使的整個團隊的加班，他會怎麼想？離開是必然的，只是時間遲早而已。

　　而且，若是你真的運氣實在不佳，提了另外一我的去取代好先生的位置，卻不幸是另外一個差先生的話，那我就只能默默地爲你點根蠟燭了。

　　那麼，爲何咱們老是習慣於忽略這個事實呢？

　　由於忽視比糾正問題容易得多——至少某種程度上，的確如此。而且沒人願意作告發同事的小人，成爲他丟掉飯碗的緣由：由於搞很差差先生上有高堂要 贍養，下有兒女嗷嗷待哺；或許他剛剛買了新房子，每月都要還貸——最重要的是，真的很難衡量開發人員的工做效率，除非你讓他們倆作相同的任務來作對比， 就像上面的故事同樣。

　　因而我一直在想這個問題：該如何衡量開發人員的工做效率。我很嫉妒作銷售的，由於他們的薪酬是根據業績來的。我有一些想法（還不成熟）能讓你去其糟粕取其精華。我也有一些想法關於如何識別、吸引和留住好的開發人員。

　　個人身份以及我爲何要告訴你這些真相

　　我曾做爲一個全職的開發人員幹了 10 多年。早在 1989 年我作出了個人第一個商業化的產品（遊戲）。雖然它並無給我帶來不少錢，但感受真的超好（那時我才 16 歲）。幾年後，我出售了其中一個遊戲點子，並最終發佈於任天堂遊戲機（以及其餘格式）上！從我經驗的角度，我能夠告訴你，當你看到你想出來的東西（包括名 稱）最終出如今商店中，這感受不要太爽。

　　2008 年，我應聘了一家技術驅動公司的一個非技術職位。我想了解企業通常的運行模式，包括銷售在內的企業中發生的全部非技術進程。雖然，個人技術能力對個人求職頗有幫助，但再也不是工做的重要組成部分。

　　我再也不爲了謀生而編程（確切的說，是當時），但常常在業餘項目上鼓搗各類新技術。對我來講，讀一本好書，既使人興奮，同時又可以獲得放鬆。

　　在我目前的崗位上，我常常會遇到一些誤解概念或缺少開發基本知識的人。而在他們身處的職位上（一般是那些 CxO 們），這些基礎知識會形成巨大的影響。

　　不少 CxO 會將開發人員看成是砌磚工人，死板地計算他們的工做效率。可是，在這裏，我想再次重申這個「做家理論」，開發人員是腦力工做者，OK？

　　-------------------------------------------------------------------------------------

　　譯文連接：http://www.codeceo.com/article/programmer-not-bricklayers.html

　　翻譯做者：碼農網 – 小峯