當人們在進行一項體力工作時，你很容易評估他們工作的努力程度。你可以看到他們的身體動作，看他們流了多少汗水。也可以去看他們的工作成果：磚牆越砌越高，地上的洞越來越大。對努力工作的認可和獎勵是人類一個非常基本的本能，這也是為什麼我們對耐力運動如此著迷的原因之一。然而，在管理一些技術創造型的員工時，這種對體力上的努力工作的本能欣賞卻變成了一個問題。高效率的知識工作者通常看起來並不像是在努力工作。
早在2004年，我還是個工作在一家有線電視公司計費和配置系統的初級開發者。像所有的大型系統一樣，它由許多相對獨立的部分組成，分別由不同個人或小團隊負責。模擬電視配置系統和數字電視配置系統幾乎是完全分開的，分別由不同的團隊負責。
模擬電視團隊已經決定在早期的微軟Biztalk平臺上開發他們的系統，由我們公司的四個夥伴和微軟的一個團隊共同開發，並負責在生產環境中執行。他們工作都非常努力，並且經常工作到夜晚，甚至週末加班。每個人都會放下自己正在做的事情去幫助解決產品問題，經常是幾個傢伙圍在一張桌子周圍，提出哪裡可能 會出現問題以及如何修復這些問題的建議。他們的工作氛圍非常活躍，僅憑這一點，任何人都能夠看出，不僅是整個團隊，而是他們每一個人都真的真的非常努力工作。
數字電視配置系統開發團隊卻是完全不同的。程式碼大部分是由一個叫戴夫的傢伙編寫的。我當時是這個團隊的一名初級維護開發者。起初，我在理解程式碼的過程中遇到了很多麻煩，因為它並不是用一個很長的程式來包含所有的內容，取而代之的是許許多多小的類檔案和僅包含幾行程式碼的方法。我的幾個同事都抱怨戴夫把程式碼搞得過於複雜。但戴夫把我招致麾下，並建議我閱讀一些物件導向程式設計方面的書籍。他教給我設計模式，SOLID程式設計原則以及單元測試。不久，我便開始能夠理解這些程式碼，而且我越研究它就越欣賞它的優雅設計。在生產環境中它周而復始的執行，沒有出現任何錯誤。程式碼改變起來也相當容易，因此，實現新的特性並不困難。單元測試則意味著要保證生產環境中儘可能少地出現bug。
這樣做的結果就是，我們看起來好像根本沒有努力工作。我每天下午5：30準時回家，週末從不加班，我們也不會擠在一起去猜測一些失敗的生產系統可能會遇到的問題。表面上看起來就像是分配給我們的任務一定是比分配給模擬電視團隊的任務容易得多。實際上，兩個團隊的需求是非常相似的，只是我們擁有一個設計和實現地更好的軟體系統，更好的支援基礎架構，尤其是單元測試。
管理部門宣佈他們將根據個人的工作表現加薪，當輪到我和老闆談話時，他說只有給那些真正努力工作的人加薪才算是公平，而我們的團隊看起來似乎並不太關心公司的發展，不能和那些犧牲了自己的休息時間來工作的人員去比較。
這家有線電視公司是一個非常少見的實驗室，你能夠對好的軟體設計和壞的軟體設計、好的團隊行為和壞的團隊行為之間的效果有一個直觀的比較。大多陣列織並不能夠進行這樣的比較。你很難判斷那些汗如雨下、工作到深夜並在週末加班、一直奮鬥在一線的傢伙是展示了他們在做一件真正複雜的系統工作時的偉大承諾，還是隻是表明了他們的失敗。除非你能夠負擔得起請兩個或者更多的競爭團隊來解決同樣的問題，但是你永遠也不會知道哪個公司會願意這樣做。相反地，那些整天朝九晚五、坐在角落裡、看似花費很多時間瀏覽網路的傢伙們呢？是隻是因為他們非常精通編寫穩定可靠的程式碼還是因為分配給他們的工作比別人的更簡單？從常人的眼光來看，第一個傢伙是在真正努力工作而第二個沒有。努力工作值得表揚，而懶惰卻是不好的，不是嗎？
我認為努力工作的表象往往意味著失敗。在一個高壓，中斷驅動的環境下，通常是不能夠進行高質量的軟體開發的。長時間工作通常也並不是一個好主意。有時解決一個困難問題的最好的方式就是停止思考，出去散個步，甚至最好去睡個覺，讓你的潛意識去解決它。我最喜歡的書籍之一，是由20世紀一位領軍的英國數學家G. H. Hardy撰寫的《A Mathematician’s Apology | 一個數學家的辯白》，他在這本書裡描述了他的日常生活：每天上午工作四個小時，然後看一整個下午的板球。他說一天中，超過四小時艱難的腦力工作是毫無意義並且徒勞的。
我想要對管理者說的是，應該根據結果及可執行的軟體來評判人們的工作，而不是通過他們看起來的努力程度來判斷。與直覺相反，你最好不要和開發者們坐在一起，這樣你才能夠對他們的產出有一個更好的、不受常規或直觀指標影響的瞭解。遠端工作非常有好處，你只能根據產出來衡量他們的貢獻，而不是簡單地看他們是否每天8小時都坐在桌前對著IDE噼裡啪啦敲鍵盤，或者是否“熱情地”圍在彼此桌前提供“有效的”建議。