懶
只有懶惰的程式設計師才會去編寫那些可以最終代替自己工作的自動化工具，才不會成天為了實現相似的功能去編寫大段大段冗餘重複的** - 這種**往往是軟體後期維護和重構的天敵。通常來說，由於惰性的驅使所產生出來的工具和程式將最終極大的提高生產開發的速度。
當然，對於乙個程式設計師來說，光光具備懶惰這個要素還是不夠的。在享受懶惰之前，他必須以最大的熱情和最高的效率去研究解放自己的途徑，比如：找到最有助於開發的工具，最能體現「一次編寫，多次復用」精神的**架構的設計。只有在這些必要的工作之後，才可能真正享受輕鬆程式設計的樂趣。
所以「懶」的精髓用一句老話來描述，那就是磨刀不誤砍柴功。如果你不想辦法磨亮手中的柴刀，就算一天二十四小時都在砍柴，效果也不如拿把鋒利的斧頭一天只砍一小時。
從這個角度來說，google給員工的20%自由時間是完全發揮了「懶」的能動力。為了更好的享受偷懶的樂趣，員工會更加具有創造力的去高效完成自己的任務。
誇張一點來說，懶惰才是人類進步的原動力。
笨
這一點似乎比懶更讓人不能接受。在解釋這裡所說的笨的具體含義之前，我們先看看乙個聰明人（或者說認為自己足夠聰明）會做什麼：
1) 停止學習新的東西
2) 不願意用批判的眼光去審視自己的工作
第1點將使我們很難去接受或者主動的去研究一項新的技術 - 即使新技術能帶給他更多工作上的便利。第2點會使我們無法清晰的分析自身工作的問題所在，要對其進行改進或者重構就更加困難。
從這兩點來考慮，作為乙個程式設計師太自以為是不見得是件好事情。由於對自身的過於自信，往往無法客觀的看待自己和自己的工作。相反的，笨一點（確切的說，謙遜一點）有時候倒有助於開發的順利進行。舉例來說，當程式出現bug的時候，最好盡早承認問題是出在自己編寫的**上面而不是在於編譯器（當然除非是位元組高低位編碼方式之類的問題，這種問題編譯器會是錯誤的根源之一）。如果你太自負的認為自己的程式沒有問題而去猜測可能是編譯器或者其他的什麼外部因素出問題的話，那麼十有**你會在除錯過程中走上一長段的彎路。
程式設計師應該笨一些的更為關鍵的原因在於，當需要思考問題的最佳解決方案的時候，往往要求我們首先要跳出思維定式。你對系統了解的越多，積累了越多的經驗，就越難走出已有的侷限，可以嘗試的範圍就越小。相反的，對於乙個什麼也不懂的門外漢來說，因為沒有任何失敗的記憶和潛規則的約束，也就沒有什麼是「不可能」的，這樣的大腦所能迸發出來的在專業人士看起來愚不可及的想法往往正是解決問題所需要的關鍵點所在。
可能很多程式設計師都會有類似的經歷，在面對別人（尤其是其他部門）對於乙個bug的描述的時候，必須把自己擺在乙個普通使用者而不是程式開發者的角度來分析問題，否則的話可能你永遠都想象不到這種錯誤也會發生。越能讓自己變得「笨」起來，越能很快的定位到問題所在。我們先看看這麼一段關於web開發問題的程式設計師和客服人員的對話：
「從昨天開始我們的使用者就看不到我們站點上的logo了。」
「他試過重啟瀏覽器麼？」
「是的。」
「他試過重啟電腦麼？」
「是的。」
「他清空過瀏覽器cache麼？」
「是的。」
「他的瀏覽器版本是ie6麼？」
「是的。」
「他確信是真的看不到logo了麼？」
「是的。」
「他是在電腦顯示器螢幕上看我們的站點麼？」
「什麼？」
「比如說，它可能是列印出來看不到？」
「不。他是在顯示器上看的。」
「除了站點logo之外，他是不是其他的都看不到？」
「什麼？哦。我再問問他。」
從這段對話來說，估計使用者實際上是禁止了瀏覽器顯示的功能（或者他兒子幹的）。不管怎麼樣，如果你不是用這種傻瓜式的思維方式去尋找答案的話，可能怎麼也找不到問題的根源。
很多時候，問題發現者對於問題的描述往往是非常片面的，並且加上了主觀推測的成分在裡面。如果你不能透過這些主觀的描述去發現問題的實際表象，或者說根本就是你自己根據程式設計師的經驗邏輯來判斷問題所在的話，十有**會在歧途上越走越遠。
對於白痴級的問題，只有用白痴的行為方式才能得到答案。
即便同樣是程式設計師，但對於你的程式並不熟悉，也會經常有這樣的疑問：「為什麼我呼叫你的**出錯了？」這種問題的答案，很多時候是因為他們的呼叫方式不對，或者呼叫了錯誤的庫檔案，或者庫檔案的版本使用不當，或者根本就沒有聯接到庫檔案上。當你想讓同事幫你檢查一下程式中的乙個莫名其妙的bug的時候，一般來說希望他對你的系統了解的越少越好，只有這樣他才會問一些你自己認為絕對不可能出問題的「笨」問題。
所以「笨」的精髓在於你如何去思考問題：不要假設些什麼，把自己假設的太完美或者把別人假設的很聰明都會使你忽視一些很淺顯的事實。思考的前提必須是完整的事實表象，思考的過程必須是拋棄成見的問題跟蹤。在發現事實之前作太多的主觀思考和臆斷，倒不如把自己當作白痴一樣來行動更好。
當然，不思考的乙個極端是不分情況都直接去做，另乙個極端是完全脫離事實，用思想辦事。乙個優秀的程式設計師應該做好權衡。10次決定裡面的1次錯誤決定不是致命的；只做5次正確的決定而另外5次沒有任何決定才更糟糕。
最後是乙個蜈蚣的故事。蜈蚣本來用自己的幾百隻腳走路走的很快很好，但他從來沒有花時間去想過為什麼。直到有一天，乙隻臭蟲問他：「你是怎麼管理好你的幾百隻腳的？你不覺得這是件很困難的事情嗎？」臭蟲問完之後就走了。只剩下蜈蚣坐在地上，不停的思考這個問題，卻一直想不出個究竟。從此以後，這只蜈蚣再也沒辦法好好的走路了。
**可能很多程式設計師都會有類似的經歷，在面對別人（尤其是其他部門）對於乙個bug的描述的時候，必須把自己擺在乙個普通使用者而不是程式開發者的角度來分析問題，否則的話可能你永遠都想象不到這種錯誤也會發生。越能讓自己變得「笨」起來，越能很快的定位到問題所在。我們先看看這麼一段關於web開發問題的程式設計師和客服人員的對話：
「從昨天開始我們的使用者就看不到我們站點上的logo了。」
「他試過重啟瀏覽器麼？」
「是的。」
「他試過重啟電腦麼？」
「是的。」
「他清空過瀏覽器cache麼？」
「是的。」
「他的瀏覽器版本是ie6麼？」
「是的。」
「他確信是真的看不到logo了麼？」
「是的。」
「他是在電腦顯示器螢幕上看我們的站點麼？」
「什麼？」
「比如說，它可能是列印出來看不到？」
「不。他是在顯示器上看的。」
「除了站點logo之外，他是不是其他的都看不到？」
「什麼？哦。我再問問他。」
從這段對話來說，估計使用者實際上是禁止了瀏覽器顯示的功能（或者他兒子幹的）。不管怎麼樣，如果你不是用這種傻瓜式的思維方式去尋找答案的話，可能怎麼也找不到問題的根源。
很多時候，問題發現者對於問題的描述往往是非常片面的，並且加上了主觀推測的成分在裡面。如果你不能透過這些主觀的描述去發現問題的實際表象，或者說根本就是你自己根據程式設計師的經驗邏輯來判斷問題所在的話，十有**會在歧途上越走越遠。
對於白痴級的問題，只有用白痴的行為方式才能得到答案。
即便同樣是程式設計師，但對於你的程式並不熟悉，也會經常有這樣的疑問：「為什麼我呼叫你的**出錯了？」這種問題的答案，很多時候是因為他們的呼叫方式不對，或者呼叫了錯誤的庫檔案，或者庫檔案的版本使用不當，或者根本就沒有聯接到庫檔案上。當你想讓同事幫你檢查一下程式中的乙個莫名其妙的bug的時候，一般來說希望他對你的系統了解的越少越好，只有這樣他才會問一些你自己認為絕對不可能出問題的「笨」問題。
所以「笨」的精髓在於你如何去思考問題：不要假設些什麼，把自己假設的太完美或者把別人假設的很聰明都會使你忽視一些很淺顯的事實。思考的前提必須是完整的事實表象，思考的過程必須是拋棄成見的問題跟蹤。在發現事實之前作太多的主觀思考和臆斷，倒不如把自己當作白痴一樣來行動更好。
當然，不思考的乙個極端是不分情況都直接去做，另乙個極端是完全脫離事實，用思想辦事。乙個優秀的程式設計師應該做好權衡。10次決定裡面的1次錯誤決定不是致命的；只做5次正確的決定而另外5次沒有任何決定才更糟糕。
最後是乙個蜈蚣的故事。蜈蚣本來用自己的幾百隻腳走路走的很快很好，但他從來沒有花時間去想過為什麼。直到有一天，乙隻臭蟲問他：「你是怎麼管理好你的幾百隻腳的？你不覺得這是件很困難的事情嗎？」臭蟲問完之後就走了。只剩下蜈蚣坐在地上，不停的思考這個問題，卻一直想不出個究竟。從此以後，這只蜈蚣再也沒辦法好好的走路了。
本文**
優秀程式設計師的兩大要素 懶 笨
優秀程式設計師的兩大要素 懶 笨 懶 只有懶惰的程式設計師才會去編寫那些可以最終代替自己工作的自動化工具，才不會成天為了實現相似的功能去編寫大段大段冗餘重複的 這種 往往是軟體後期維護和重構的天敵。通常來說，由於惰性的驅使所產生出來的工具和程式將最終極大的提高生產開發的速度。當然，對於乙個程式設計師...
優秀程式設計師的兩大要素 懶 笨
懶只有懶惰的程式設計師才會去編寫那些可以最終代替自己工作的自動化工具，才不會成天為了實現相似的功能去編寫大段大段冗餘重複的 這種 往往是軟體後期維護和重構的天敵。通常來說，由於惰性的驅使所產生出來的工具和程式將最終極大的提高生產開發的速度。當然，對於乙個程式設計師來說，光光具備懶惰這個要素還是不夠的...
優秀程式設計師的兩大要素 懶 笨
這兩個詞和優秀聯絡起來，似乎有些不可思議。但從辯證的角度來看，這兩項要素確實是成為一名好的程式設計師所應該具備的。philipp lenssen的原文 請看這裡 懶 只有懶惰的程式設計師才會去編寫那些可以最終代替自己工作的自動化工具，才不會成天為了實現相似的功能去編寫大段大段冗餘重複的 這種 往往是...