看看編程的大神們怎麼說。
|
我認識到一個非常有悖常理的現象，優秀的程序員都是即懶又傻的。
因爲懶，他纔會寫出各種各樣的工具來替自己幹活。因爲懶，他纔會想辦法避免去寫無聊重複的代碼——因此避免的代碼的冗餘，消減了維護的成本，使重構變得容易。最終，這些由於懶惰激發出的動力而開發出的工具和最佳編程實踐方法提升了產品的質量。
懶惰的程序員也因此變成了優秀的程序員。當然，這只是事情的一部分；從一個懶惰的程序員變成一個優秀的程序員，他/她會在學習如何能夠永遠保持懶惰時表現出驚人的不懶惰——也就是，什麼樣的軟件工具能讓自己幹活更輕鬆，什麼方法能避免繁冗，如何能讓工作更容易的維護和重構。
其次，(我將用多一點篇幅來說明這一點，因爲我發現這個觀點比第一個更難接受。)優秀的程序員都是傻的。爲什麼？因爲如果他很聰明，或他知道自己很聰明，他就會：
第一點將會導致他不再努力的去發現新的技術，讓自己工作的更快捷。第二點將導致他的代碼變得難以debug，難以重構。在程序員和編譯器無休止的戰爭中，程序員最好一開始就投降並承認是自己的錯，而不是編譯器的錯(除非是關於字符編碼問題，有些編譯器確實有問題)。
但是，還有一個優秀的程序員必須笨的更重要的理由。爲了尋找到更好的問題解決方案，他必須保持一個謙虛的心態，他必須跳出模式想問題。某種程度上，這會讓他們回到小孩的思維模式；因從未經歷“no”的打擊而極具創造力。
相反的思維模式就不是那麼具有創見性，會認爲對現狀瞭如指掌，會接受現狀。可是又有誰知道多少你認爲的不可能是真正的不可能？知道的越少你就會越激進。你開發的工具越好，你的產品就會因爲它們變得質量更高。
我從工作中總結出，一個優秀的程序員，在從經理那裏確認一個需求時，他需要以一個笨人的思維模式；他會從最簡單的，孩子般的問題問起。他不會想當然的接受這個問題提供者提供的信息。在web開發中一個典型的交談會是這樣：
“昨天，一個客戶說我們網站上的logo圖片無法顯示。” “他重啓瀏覽器了嗎？” “是的。” “他重啓計算機了嗎？” “是的。” “他清空緩存了嗎？” “是的。” “他用的是IE6嗎？” “是的。” “他確信是沒看見嗎？” “是的。” “他是在電腦屏幕上看我們的網站嗎？” “什麼?” “是這樣，他也許把它打印了出來。” “不，看是盯着屏幕看的。” “除了logo，他能看到網站上的其它圖片嗎？” “什麼？哦，我問問。”
爲了說明我們的主題(這個故事完全是虛構的)，我們假設客戶真的關閉了瀏覽器的圖片顯示。也許是他兒子乾的。不管怎樣，如果你用“聰明”的模式思考，你很難找出這樣的答案。所以這個程序員問的問題都不需要任何的編程知識。因爲這是一個很傻的問題，所以只有傻辦法才能解決。
數年前，我曾就因爲我的一次更新而弄壞整個網站的事情進行了一此很長的電話討論….事實證明是因爲那個傢伙把他的瀏覽器的CSS給禁掉了。從那時起，我就開始懷疑一切，而不是因爲這樣一個簡單的事情而聆聽一個半小時什麼是代碼質量的抱怨。最終，猜測是我的更新出了問題….只是一個猜測。如果你想解決問題，最好的方法是隻聽事實部分，不要聽他們認爲的可能的原因。
相似的，當同事問我：“這爲什麼不好用？”大多數時候是因爲他們修改錯了問題(例如，他想鏈接lib1，但他實際鏈接的是lib2，或事實上他根本沒有鏈接任何lib)。當你向一個同事求助，尤其是編程問題，你一般不會告訴他更多關於項目的事情。當他問一些很傻的問題時，你潛意識裏就會抵制回答，因爲你認爲你知道的很清楚，但事實上你並不是這樣。
事情當然有另外一面。太笨也就想不出任何辦法，做錯事，解決不了任何問題。而太聰明的喜歡坐着計劃好問題，但卻很少行動。實用主義的程序員取其中。他知道，10次決策一次錯誤比起只有五次正確決定而另五次什麼都不做要好的多。
這有點像一個關於蜈蚣的故事。蜈蚣很擅長使用它的100條腿一起走路。它從來沒有想過它是如何能做到這些的。直到有一天，一個臭蟲問他，“你是如何控制這麼多腿走路的？你不覺得讓它們按一定的節奏配合走路很難嗎？”臭蟲說完就走了，蜈蚣卻仍然坐在那裏思考，思考如何走路的，不解，甚至(此生中的第一次)有些擔心了。從那天起，這個蜈蚣再也沒能走一步。
所以，如果你想實現某個事情，不要想太多。當然，這也只是事情的一半…. |
