懶 只有懶惰的程序員才會去編寫那些可以最終代替自己工作的自動化工具，才不會成天為了實現相似的功能去編寫大段大段冗余重復的代碼 - 這種代碼往往是軟件后期維護和重構的天敵。通常來說，由于惰性的驅使所產生出來的工具和程序將最終極大的提高生產開發的速度。

　　當然，對于一個程序員來說，光光具備懶惰這個要素還是不夠的。在享受懶惰之前，他必須以最大的熱情和最高的效率去研究解放自己的途徑，比如：找到最有助于開發的工具，最能體現“一次編寫，多次復用”精神的代碼架構的設計。只有在這些必要的工作之后，才可能真正享受輕松編程的樂趣。

　　所以“懶”的精髓用一句老話來描述，那就是磨刀不誤砍柴功。如果你不想辦法磨亮手中的柴刀，就算一天二十四小時都在砍柴，效果也不如拿把鋒利的斧頭一天只砍一小時。

　　從這個角度來說，Google給員工的20%自由時間是完全發揮了“懶”的能動力。為了更好的享受偷懶的樂趣，員工會更加具有創造力的去高效完成自己的任務。

　　夸張一點來說，懶惰才是人類進步的原動力。

　　笨 這一點似乎比懶更讓人不能接受。在解釋這里所說的笨的具體含義之前，我們先看看一個聰明人（或者說認為自己足夠聰明）會做什么：

　　1) 停止學習新的東西
　　2) 不愿意用批判的眼光去審視自己的工作

　　第1點將使我們很難去接受或者主動的去研究一項新的技術 - 即使新技術能帶給他更多工作上的便利。第2點會使我們無法清晰的分析自身工作的問題所在，要對其進行改進或者重構就更加困難。

　　從這兩點來考慮，作為一個程序員太自以為是不見得是件好事情。由于對自身的過于自信，往往無法客觀的看待自己和自己的工作。相反的，笨一點（確切的說，謙遜一點）有時候倒有助于開發的順利進行。舉例來說，當程序出現bug的時候，最好盡早承認問題是出在自己編寫的代碼上面而不是在于編譯器（當然除非是字節高低位編碼方式之類的問題，這種問題編譯器會是錯誤的根源之一）。如果你太自負的認為自己的程序沒有問題而去猜測可能是編譯器或者其他的什么外部因素出問題的話，那么十有八九你會在調試過程中走上一長段的彎路。

　　程序員應該笨一些的更為關鍵的原因在于，當需要思考問題的最佳解決方案的時候，往往要求我們首先要跳出思維定式。你對系統了解的越多，積累了越多的經驗，就越難走出已有的局限，可以嘗試的范圍就越小。相反的，對于一個什么也不懂的門外漢來說，因為沒有任何失敗的記憶和潛規則的約束，也就沒有什么是“不可能”的，這樣的大腦所能迸發出來的在專業人士看起來愚不可及的想法往往正是解決問題所需要的關鍵點所在。

　　可能很多程序員都會有類似的經歷，在面對別人（尤其是其他部門）對于一個bug的描述的時候，必須把自己擺在一個普通用戶而不是程序開發者的角度來分析問題，否則的話可能你永遠都想象不到這種錯誤也會發生。越能讓自己變得“笨”起來，越能很快的定位到問題所在。我們先看看這么一段關于web開發問題的程序員和客服人員的對話：

　　“從昨天開始我們的用戶就看不到我們站點上的Logo了。”
　　“他試過重啟瀏覽器么？”
　　“是的。”
　　“他試過重啟電腦么？”
　　“是的。”
　　“他清空過瀏覽器Cache么？”
　　“是的。”
　　“他的瀏覽器版本是IE6么？”
　　“是的。”
　　“他確信是真的看不到Logo了么？”
　　“是的。”
　　“他是在電腦顯示器屏幕上看我們的站點么？”
　　“什么？”
　　“比如說，它可能是打印出來看不到？”
　　“不。他是在顯示器上看的。”
　　“除了站點Logo之外，他是不是其他的圖片都看不到？”
　　“什么？哦。我再問問他。”

　　從這段對話來說，估計用戶實際上是禁止了瀏覽器顯示圖片的功能（或者他兒子干的）。不管怎么樣，如果你不是用這種傻瓜式的思維方式去尋找答案的話，可能怎么也找不到問題的根源。