如果你有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？
來自：碼農網
評論(1)