你的程序員是在努力工做仍是在偷懶？

　Mike Hadlow 是一位資深軟件開發者，同時也是 EasyNetQ 與 Suteki Shop 的做者，喜好歷史與科技，是一個技術極客。近日，Mike 就程序員工做效率、工做表現以及工做成果等主題撰寫了一篇博客，談到了咱們該如何看待程序員究竟是在努力工做仍是在偷懶這個問題。

　　若是人們從事的是體力勞動，那麼咱們就很容易可以看出他們工做的努力程度。你會直觀、清楚地看到他們頻繁移動的步伐，流下的汗珠。還會看到他們 工做的成果：逐漸升起的磚牆，地上的洞變得愈來愈深，等等。觀察到並獎勵努力工做的人是人類的一種很基本的天性，這也是咱們以爲忍耐力運動使人着迷的緣由 之一。不過對於管理技術創造性的員工來講，這種對努力的體力勞動自然的欣賞之情就會出現問題。高效的知識工做者經常看起來並非那麼努力工做。

　　回到 2004 年，那時我仍是一名初級開發者，工做在一個大型團隊中，主要從事有線電視公司的帳單與供應系統。就像全部的大型系統同樣，這個系統由大量相對比較獨立的組 件構成，不一樣的小組負責不一樣的組件開發工做。模擬電視與數字電視供應系統幾乎是徹底分開的，由兩個不一樣的小組分別進行開發。

　　模擬電視團隊決定根據 Microsoft Biztalk 的一個早期版原本構建他們的系統。團隊有 4 我的以及一個來自於微軟的團隊共同開發並運行這個系統。他們看起來工做很是努力，經常工做到深夜，週末也在加班加點。當遇到生產問題時，團隊的每一個人都會 放下手頭的工做，圍攏在一塊兒，提供各類建議和意見，以及如何修復問題的看法。你會看到，這個團隊中的每一個人都有很強的團隊凝聚力，並且他們工做都很是努 力。

　　數字電視供應系統則截然不同。系統的代碼幾乎是由一個傢伙搞定的，咱們暫且稱這個傢伙爲 Dave 吧。我是團隊的一名初級維護工程師。一開始，我在理解代碼時遇到了不少麻煩。程序中並無長長的過程語句，相反有大量的小體積類和方法，每一個方法的代碼也 只有寥寥數行而已。我有幾個同事抱怨 Dave 將事情搞得過於複雜了。不過 Dave 卻建議我應該閱讀幾本關於面向對象編程的圖書。他教會了我設計模式、SOLID 原則以及單元測試等知識。很快，他所編寫的代碼開始變得具備現實意義了，隨着我不斷加深對代碼的理解，我也愈來愈發現它優雅的設計。代碼在產品中沒有出現 問題，只是一直在默默地工做。要想對代碼作出修改也是垂手可得的事情，所以實現新的特性簡直是手到擒來。單元測試意味着進入到生產系統中的 Bug 數量變得微乎其微。

　　結果就是咱們這個團隊看起來工做不那麼努力。我天天下午5:30 下班，週末也歷來不用工做，咱們也沒必要圍聚在一塊兒猜想究竟是什麼緣由致使了生產系統的問題。從外人的角度來看，咱們所從事的工做確定要比模擬電視團隊的簡 單得多。事實上，兩者的需求很是相像，只是咱們開發出了設計更好的軟件、提供了更好的支持基礎設施，特別是單元測試。

　　管理團隊宣佈要根據績效給予員工獎勵。輪到老闆與我談話時，他說公平的作法是對那些努力工做的員工給予獎勵，工做越努力，獎勵力度越大，咱們的團隊看起來對公司並不那麼在乎，更沒法與那些放棄晚間與週末時間的英雄相提並論。

　　這家有線電視公司有一點不同凡響，你能夠直接比較好的軟件設計與差的軟件設計之間的差異，還能夠對團隊行爲進行比較。大多數組織者都並無提供 這一比較。咱們很難說某個員工是否是通宵達旦地工做，甚至週末時間也在工做，頻繁充當救火隊員的角色，這種作法是否是就是複雜軟件系統必需要作的呢。除非 你可讓幾個互相競爭的團隊解決同一問題，不然你永遠也無法直接比較他們工做上的差異。相反，對於那個坐在角落裏，朝九晚五工做的傢伙有可能花了不少時間 在上網呢？也許他很是善於編寫穩定、可靠的代碼，也許他的工做要比其餘人的簡單。對於偶爾過來檢查的管理者來講，他們會以爲第一種人工做很努力，第二種人 則不是這樣。努力工做就很好，偷懶就很很差，真的是這樣麼？

　　個人見解是表面上的努力工做經常是失敗的信號。高壓力、頻繁中斷的環境經常沒法開發出好的軟件。長時間的工做也不是一種正確的作法。有時，解決 難題最好的方式多是再也不思考這個問題，出去走走，或是睡個好覺，讓你的潛意識來解決問題。我最喜歡的一本書是G. H. Hardy 所編寫的 A Mathematician’s Apology，他是 20 世紀英國的一位傑出數學家。這本書描繪了他天天的工做：上午工做 4 個小時，下午觀看板球比賽。他說對於複雜的腦力工做來講，一天工做 4 個小時以上是徹底沒有意義且生產力低下的方式。

　　我想對管理者說的是，以結果爲導向，根據員工工做的成果，根據可運行的軟件爲導向，不要被人們表面上的努力工做所矇蔽。另外，最好不要與你的開 發者坐在一塊兒，你會獲得更好的結果，不受傳統、直覺判斷所影響的好結果。遠程工做的好處是很是多的，你只能以輸出來衡量員工的工做狀況，而不是看他們是不 是天天端坐 8 小時盯着 IDE 在看爲標準，或是彙集在一塊兒提出本身的看法爲衡量的準則。

　　有讀者評論說，文章寫的很實在，有時真的很難說服同事設計的簡單性與恰當使用 OO 原則所帶來的好處。我就看到有的人以編寫複雜代碼並工做到深夜爲傲。

　　還有讀者說，我曾經與一個傢伙共事過，他說「第一次就將事情作對的困難之處在於沒有人認識到事情會有多麼複雜」。幾年過去了，我發現這句話很是正確。我如今都會在項目開始前進行大量的提早設計。這經常會讓執行變得很是平滑，不過可能會讓其餘人以爲這件事挺簡單的。

來自: InfoQ