141、Herbert Simon 報告了關于人類解決問題的一系列試驗，發現人們并不總能自行找出解決問題的巧妙辦法，即使這些辦法很容易傳授給他們（Simon 1996)。換句話說，就算你想再發明個車輪，也不會注定成功，你發明的也許是方車輪。
142、“硬幹”或者“苦幹”并沒有帶着光環。“硬幹”是種徒勞的、大可不必的努力，隻會說明你急切但并不是在完成工作。人們容易混淆行動與進展，混淆忙碌與多産。有效程式設計中最重要的工作是思考，而人思考時通常不會看上去很忙。如果和我共事的程式員總是忙個不停，我會認為他并非優秀的程式員，因為他沒用最有價值的工具------自己的腦袋。
144、根據環境的不同，堅持可能是财富，也可能是負擔。和大部分的中性詞一樣，依據你的褒貶意圖而有不同的意思。如果你想表達貶意，可以說是“固執已見”或“頑固不化”；如果你要表達褒意，可以說是“堅韌不拔”或“持之以恒”。
多數時候軟體開發中的堅持其實就是沒有好處的“固執”。當在某段新代碼上卡殼時，堅持很難讓人稱道。不妨另辟蹊徑，嘗試重新設計類，或者繞過去，以後回頭再試。當一種辦法行不通時，正好可以換個辦法試試（Pirsig 1974)。
高度時，花四個小時幹掉某一錯誤肯定會很有滿足感；但通常最好隻要有一段時間沒有進展，比如說15分鐘，就該放棄排錯過程，讓潛意識仔細品品。想個其他法子将問題繞開；從頭編寫有麻煩的代碼段；理清思緒後再來做。和計算機錯誤鬥氣是不明智的，更好的方法是避開它們。
知道何時放棄很難，但這是必須面對的問題。當你遭受挫折時，提出此問題正是時候。提出并不是說這時就放棄，而是該為目前的行為設定底牌了：“要是這種方法三十分鐘之内還不解決問題，我就會花十分種想些其他辦法，再用一個鐘頭嘗試最可行的辦法。”
145、與其他行業相比，軟體開發行業的經驗比書本知識價值要小，這有幾個原因：在其他許多行業裡，基礎知識變化得很慢。即便晚你10年畢業的人，他所學的基礎知識還和你那時學的一模一樣；而軟體開發，即使基礎知識也變化很快，晚于你10年畢業的人所學的有效程式設計技術，其數量有可能是你的兩倍。一些老程式員往往被看作另類，不僅是因為從未接觸某些專項技術，還因為他們沒有用過從學校畢業之後出名的基本程式設計概念。
146、if語句的使用
糟糕的if語句使用方法：
好的if語句：
146、case的使用範圍
case語句應該用于處理簡單的、容易分類的資料。如果你的資料并不簡單，那麼就使用if-then-else語句串。
147、表驅動的好處
用邏輯語句
用表的方法
148、軟體開發的規模擴大并不是像“拿一個小項目來，然後增大它的每一部分”那樣簡單。假設你花費20個人月開發了一套有25000行代碼的Gigatron(千兆子）軟體包，并在領域測試試中找出500個錯誤。再假設Gigatron1.0很成功，Gigatron2.0也一樣成功，現在你正在着手開發Gigatron Deluxe版，該版本将對該程式做出重大更新，預計将有250000行代碼。
雖然它的規模是最初Gigatron的10倍，但是開發Gigatron Deluxe版的工作量卻不是原來工作量的10倍；而是30倍。此外，整體工作量增長為30倍并不意味着建構活動的工作量就會增長為30倍。很可能是，建構活動的工作量增長為25倍，架構和系統測試工作量增長為40倍。你的得到的錯誤數量也不會增長為10倍，而會是15倍甚至更高。
如果你習慣于開發小項目，那麼你的第一個中大型項目有可能嚴重失控，它不會像你憧憬的那樣成功，而會變成一頭無法控制的野獸。
149、更大的項目要求采取一些組織技術來改善交流效率，或者有意識地對其加以限制。
改善交流效率的常用方法是采用正式的文檔。不是讓50個人以各種可能方式互相交流，而讓他們閱讀和撰寫文檔。有些文檔是文本，有些是圖形。有些文檔需要列印出來，有些則是電子格式。
150、項目的規模既會影響錯誤的數量，也會影響錯誤的類型。你也許不曾想到錯誤類型也會受到影響，然而随着項目規模的增大，通常更大一部分錯誤要歸咎于需求和設計。