當一個人在完成一件體力工作時，你很容易評估他是否在努力的工作。你可以觀察他的物理動作，看他流了多少汗水。你還可以看到他工作的成功：磚牆在砌高，地面上挖的坑在變大。對努力工作的認可和褒獎是人性中非常基本的本能反應。這也正是爲什麼人們對體力耐力體育活動如此着迷的原因之一。這種對體力上的辛苦工作的本能的賞識，在遇到管理一羣技術創造型的員工時，卻成了一個麻煩問題。高效的腦力工作者通常會被看作並沒有在努力的工作。
早在2004年，我還是一個初級程序員，工作在一家有線電視公司，在一個大型團隊中開發財務和供銷系統。跟所有的大型系統一樣，這個系統由很多的相對獨立的模塊組成，分別由一些個人或小團隊負責。其中模擬電視和數字電視的財務和供銷系統幾乎完全獨立，分別由兩個團隊開發。
模擬電視開發組決定在早期的微軟Biztalk平臺上開發他們的系統。由這個公司的4個小夥和微軟的一個團隊共同開發，並負責產品環境的運行。他們看起來真的工作的十分辛苦和努力。你經常能看到他們加班到深夜或週末加班。每個人都會隨時放下手中的活兒來解決正式環境中突現的問題，經常會在一張桌子前一羣人圍繞着一個小夥，各自說出自己的見解，討論什麼地方錯了，應該如何修正。工作氣氛永遠是熱火朝天，每個人都能看到這些——即使只是經過瞟一眼，不僅僅從整個團隊講，而是他們每個人都真的真的工作的很努力。
數字電視供銷系統開發團隊卻是完全的不同。代碼幾乎是由一個傢伙寫的，我們就叫他大衛吧。我是一個初級程序員，在團隊裏做維護工作。起初我在理解他的代碼時遇到了很大的麻煩。他的代碼裏沒有很長的過程，通常我的代碼會把很多操作放到一起，相反，他的代碼裏有大量的很小的類文件和只有幾行代碼的小方法。好幾個同事都抱怨大衛把代碼搞的過度複雜了。但大衛耐心教導我，建議我去讀幾本面向對象編程的書籍。他給我講設計模式，SOLID編程原則，單元測試等知識。很快，我對他的代碼開始有了理解，我越研究他的代碼，越欣賞這些程序中優雅的設計。這些代碼放到產品環境中非常好用，運行穩定的幹着它們的工作。這些代碼修改起來也相當簡單，因此，一些新功能的增加變得輕鬆容易。單元測試保證了大部分的bug都阻擋到了正式環境之外。
這些做法產生的結果就是，我們看起來完全不是在十分努力的工作。我們5點半準時下班，週末從來沒有加過班，我們從來沒有發生過一大羣人圍繞着一個人數小時的討論正式環境中的錯誤是怎麼發生的場景。在外人看來，我們肯定是被分配了一件相對容易的任務。但事實上，需求都是十分相似的，我們只是更好的設計和實現了這個系統，有更好的支持系統基礎架構，特別是單元測試。
管理部門宣稱他們要根據員工的工作表現漲薪。當輪到老闆跟我談話時，老闆說只給那些工作真的努力的員工漲工資才顯的公平。而我們的團隊看起來對公司發展的好壞並不太在意——跟那些放棄了自己的晚上和週末的英雄們相比。
這家公司是一個稀有的實驗室，你可以將好的軟件設計和壞的軟件設計、好的團隊特徵和不好的團隊特徵的影響效果做一個直接的對比觀察。大多數的公司裏不可能提供這種比較的機會。你很難說這些揮汗如雨、工作到深夜和週末、堅持衝在滅火第一線的小夥們是爲了開發一個真的非常非常複雜的系統而展示了偉大的付出，還是就是一次失敗。除非你有能力提供兩個團隊來競爭，讓他們解決同樣的問題，可是哪個公司願意做這樣的事情呢。相反，如何看待那些坐在角落裏，朝九晚五，看着像是整天上網讀什麼東西的程序員呢？是他們善於寫出強健穩定的代碼嗎？還是分配的活兒比其他人容易？在常人的眼裏，前一個團隊的小夥們是在努力的工作，而第二個不是。努力工作值得讚揚，懶惰可恥，不是嗎？
我敢斷言，表面上看起來工作很努力通常會是一種失敗的信號。在高壓下，在一個不斷被打攪的環境中，軟件開發通常是不能幹好的。長時間的工作往往不是一個好的方式。有時解決一個難題的最好的方法是停止思考，出去散散步，或更好的，去睡一個好覺，讓潛意識幫你解決。我最喜歡的一本書就是20世紀英國數學界領軍人物G. H. Hardy先生寫的《A Mathematician’s Apology》。在這本書裏，Hardy先生描述他的日常規律：上午4小時的工作，下午看板球比賽。他說一天超過四小時的高強度腦力勞動都是無意義的，也是無效率的。
對於那些管理者們，我想說的是，判斷一個人要看結果，要看開發出的軟件的好用與否，而不是看他們表現的是如何在努力的工作。很反直覺吧，你其實最好不要坐在這些程序員中間，這樣能保證你不受傳統的、本能上的評判指標的影響，這樣你才能對他們的產出有更好的認識。遠程工作是特別有效的一種做法，你只能通常他們的產出來評判他們，而不是省事的觀察他們是否8小時都坐在辦公桌前對着IDE噼裏啪啦的敲着鍵盤或“熱心的”圍聚在另外一個人的桌前提供着“有效的”建議。
[英文原文：Are Your Programmers Working Hard, Or Are They Lazy? ]