[[92739]]

當一個人在完成一件體力工作時，你很容易評估他是否在努力的工作。你可以觀察他的物理動作，看他流了多少汗水。你還可以看到他工作的成功：磚墻在砌 高，地面上挖的坑在變大。對努力工作的認可和褒獎是人性中非?；镜谋灸芊磻?。這也正是為什么人們對體力耐力體育活動如此著迷的原因之一。這種對體力上的 辛苦工作的本能的賞識，在遇到管理一群技術創(chuàng)造型的員工時，卻成了一個麻煩問題。高效的腦力工作者通常會被看作并沒有在努力的工作。

早在2004年，我還是一個初級程序員，工作在一家有線電視公司，在一個大型團隊中開發(fā)財務和供銷系統。跟所有的大型系統一樣，這個系統由很多的相對獨立的模塊組成，分別由一些個人或小團隊負責。其中模擬電視和數字電視的財務和供銷系統幾乎完全獨立，分別由兩個團隊開發(fā)。

模擬電視開發(fā)組決定在早期的微軟Biztalk平臺上開發(fā)他們的系統。由這個公司的4個小伙和微軟的一個團隊共同開發(fā)，并負責產品環(huán)境的運行。他們看起來真 的工作的十分辛苦和努力。你經常能看到他們加班到深夜或周末加班。每個人都會隨時放下手中的活兒來解決正式環(huán)境中突現的問題，經常會在一張桌子前一群人圍 繞著一個小伙，各自說出自己的見解，討論什么地方錯了，應該如何修正。工作氣氛永遠是熱火朝天，每個人都能看到這些——即使只是經過瞟一眼，不僅僅從整個 團隊講，而是他們每個人都真的真的工作的很努力。

數字電視供銷系統開發(fā)團隊卻是完全的不同。代碼幾乎是由一個家伙寫的，我們就叫他大衛(wèi) 吧。 我是一個初級程序員，在團隊里做維護工作。起初我在理解他的代碼時遇到了很大的麻煩。他的代碼里沒有很長的過程，通常我的代碼會把很多操作放到一起，相 反，他的代碼里有大量的很小的類文件和只有幾行代碼的小方法。好幾個同事都抱怨大衛(wèi)把代碼搞的過度復雜了。但大衛(wèi)耐心教導我，建議我去讀幾本面向對象編程 的書籍。他給我講設計模式，SOLID編程原則，單元測試等知識。很快，我對他的代碼開始有了理解，我越研究他的代碼，越欣賞這些程序中優(yōu)雅的設計。這些 代碼放到產品環(huán)境中非常好用，運行穩(wěn)定的干著它們的工作。這些代碼修改起來也相當簡單，因此，一些新功能的增加變得輕松容易。單元測試保證了大部分的 bug都阻擋到了正式環(huán)境之外。

這些做法產生的結果就是，我們看起來完全不是在十分努力的工作。我們5點半準時下班，周末從來沒有加過班， 我們從來沒有發(fā)生過一大群人圍繞著一個人數小時的討論正式環(huán)境中的錯誤是怎么發(fā)生的場景。在外人看來，我們肯定是被分配了一件相對容易的任務。但事實上， 需求都是十分相似的，我們只是更好的設計和實現了這個系統，有更好的支持系統基礎架構，特別是單元測試。

管理部門宣稱他們要根據員工的工作表現漲薪。當輪到老板跟我談話時，老板說只給那些工作真的努力的員工漲工資才顯的公平。而我們的團隊看起來對公司發(fā)展的好壞并不太在意——跟那些放棄了自己的晚上和周末的英雄們相比。

這 家公司是一個稀有的實驗室，你可以將好的軟件設計和壞的軟件設計、好的團隊特征和不好的團隊特征的影響效果做一個直接的對比觀察。大多數的公司里不可能提 供這種比較的機會。你很難說這些揮汗如雨、工作到深夜和周末、堅持沖在滅火第一線的小伙們是為了開發(fā)一個真的非常非常復雜的系統而展示了偉大的付出，還是 就是一次失敗。除非你有能力提供兩個團隊來競爭，讓他們解決同樣的問題，可是哪個公司愿意做這樣的事情呢。相反，如何看待那些坐在角落里，朝九晚五，看著 像是整天上網讀什么東西的程序員呢？是他們善于寫出強健穩(wěn)定的代碼嗎？還是分配的活兒比其他人容易？在常人的眼里，前一個團隊的小伙們是在努力的工作，而 第二個不是。努力工作值得贊揚，懶惰可恥，不是嗎？

我敢斷言，表面上看起來工作很努力通常會是一種失敗的信號。在高壓下，在一個不斷被打 攪 的環(huán)境中，軟件開發(fā)通常是不能干好的。長時間的工作往往不是一個好的方式。有時解決一個難題的最好的方法是停止思考，出去散散步，或更好的，去睡一個好 覺，讓潛意識幫你解決。我最喜歡的一本書就是20世紀英國數學界領軍人物G. H. Hardy先生寫的《A Mathematician’s Apology》。在這本書里，Hardy先生描述他的日常規(guī)律：上午4小時的工作，下午看板球比賽。他說一天超過四小時的高強度腦力勞動都是無意義的，也是無效率的。

對 于那些管理者們，我想說的是，判斷一個人要看結果，要看開發(fā)出的軟件的好用與否，而不是看他們表現的是如何在努力的工作。很反直覺吧，你其實最好不要坐在 這些程序員中間，這樣能保證你不受傳統的、本能上的評判指標的影響，這樣你才能對他們的產出有更好的認識。遠程工作是特別有效的一種做法，你只能通常他們 的產出來評判他們，而不是省事的觀察他們是否8小時都坐在辦公桌前對著IDE噼里啪啦的敲著鍵盤或“熱心的”圍聚在另外一個人的桌前提供著“有效的”建議。

原文鏈接：http://mikehadlow.blogspot.co.uk/2013/12/are-your-programmers-working-hard-or.html

譯文鏈接：http://www.aqee.net/are-your-programmers-working-hard-or-are-they-lazy/