1. 20世紀80年代，豐田公司的流水作業線因爲它在缺陷預防方法上的革新變得出了名的高效。每個發現自己的部門有問題的成員都有權暫停生產。這個方法意在寧可發現問題後馬上暫定生產、解決問題，也不能由其繼續生產而導致更棘手且更高代價的修復/更換/召回後的問題。
2. 代碼設計是否糟糕，從某些地方就可以看出來。比如：
a. 超大類或超大函數
b. 大片被註釋的代碼
c. 邏輯重複
d. If/else嵌套過深
3. 如果你的團隊突然失去了一個主力成員，你會怎麼辦？生意依舊進行還是戛然而止？
很不幸，大多數軟件團隊都陷入了後一種情況。這些團隊把他們的開發人員培養成了只會處理他們自己專業領域的“領域專家”。起初，這看起來是一個比較合理的方法。它對汽車製造裝配生產線很適用，但是爲什麼對軟件開發團隊就不行呢?畢竟，想讓每個成員都掌握所編程序的細微差別也不太可能，對吧?問題是開發人員不容易輕易替換掉。雖然當每位成員都可用時，“抽屜方法”很有效，但如果當“領域專家”突然因人事變動、疾病或突發事故而無法工作 時，抽屜 方法立馬土崩瓦解。(所以，)軟件團隊有一些看似多餘實則重要的後備力量至關重要。代碼複查、結對編程和共有代碼可以成功營造一個環境，在這個環境中， 每位開發人員至少表面上是熟悉自己非擅長領域之外的系統部分。
4. 不要留着“破窗戶”(低劣的設計、錯誤的決策或者糟糕的代碼)不修。
發現一個就修一個。 如果沒有足夠的時間進行適當的修理，就先把它保留起來。或許你可以把出問題的代碼放到註釋中，或是顯示“未實現”消息，或用虛擬數據加以替代。採取一些措施，防止進一步的惡化。這表明局勢尚在掌控之中。
編程社區就好像一個現實社區。每個作品都是一個開發者的縮影。糟糕的代碼發佈的越多，就越容易反映現狀。如果你不去努力編寫優秀、整潔和穩定的代碼，那你每天都將和糟糕的代碼相伴了。
同樣地，如果你看到別人寫出了糟糕的代碼，你就要跟這個人提出來。注意，這時候機智就應該用上場了。一般情況下，程序員都願意承認他們在軟件開發中還是有不懂的地方，並且會感謝你的好意。
5. 雙鳥在林，不如一鳥在手
如果可以討論系統架構和重構，那麼就差找個時間把事情做完。爲了使正常運作的東西更加簡潔而做改動，權衡改動的利弊很重要。當然了，簡潔是一個理想目標，但總會有可以通過重構改進的代碼。在編程世界中，爲了代碼不過時，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那麼，你面臨一個簡單窘境：你不能一石二鳥。你在重構舊代碼上所花時間越多，你編寫新代碼的時間就越少。在及時改進代碼和維護程序之間，也需要找到平衡點。
6. 能力越大，責任越大
毫無疑問，軟件已成爲我們生活中一個既基本又重要的一部分。正因如此，開發優秀軟件格外重要。乒乓球遊戲中的Bug是一回事，航天飛機導向系統或者 航空交通管制系統中的Bug是另外一回事。Slashdot曾發表一文，講述了單單Google News的一個小失誤使一家公司股票蒸發11.4億美元。其他例子參見《軟件Bug引發的十次嚴重後果》。這些例子便說明了我們正行使着多大的權利。你今 天寫的代碼，無論你是否有意，說不定有朝一日在重要的應用程序中派上用場，這想想都令人害怕。編寫正確合格的代碼吧!
7. 一個程序員用在寫程序上的時間大概佔他的工作時間的10-20%，大部分的程序員每天大約能寫出10-12行的能進入最終的產品的代碼 — —不管他的技術水平有多高。 好的程序員花去90%的時間在思考、研究和實驗，來找出最優方案。差的程序員花去90%的時間在調試問題程序、盲目的修改程序，期望某種寫法能可行。
8. 偉大的程序員只花很少的時間去寫代碼——至少指那些最終形成產品的代碼。那些要花掉大量時間寫代碼的程序員都是太懶惰，太自大，太傲慢，不屑用現有的方案去解決老問題。偉大的程序員的精明之處在於懂得欣賞和重複利用通用模式。好的程序員並不害怕經常的重構(重寫)他們的代碼以求達到最好效果。差的程序員寫的代碼缺乏整體概念，冗餘，沒有層次，沒有模式，導致很難重構。把這些代碼扔掉重做也比修改起來容易。
9. 儘管大多數軟件都是團體開發的，但這並不是一項民/主的活動。通常，一個人負責設計，其他人負責實現細節。
10. 編程是個很難的工作。是一種劇烈的腦力勞動。好的程序員7×24小時的思考他們的工作。他們最重要的程序都是在淋浴時、睡夢中寫成的。因爲這最重要的工作都是在遠離鍵盤的情況下完成的，所以軟件工程不可能通過增加在辦公室的工作時間或增加人手來加快進度。
11. 簡單是穩定的前提，任何優秀的大軟件裏面都是一個個優秀的小程序。
12. 對於增加一個功能點所付出的代價，你要明白的很重要的一點就是，它不僅僅指開發這個功能所消耗的時間。它同時還包括帶來的額外的給以後擴展造成的困難。不錯，任何的功能特性都是能實現的——只要有足夠的時間。除了這些將來會出現的問題外，你最終還會使你的程序變得脆弱，最終連一個絕對簡單的功能都越來越難以和現有的混亂的web結合起來。應對此問題的辦法是你應只接受那些不會導致衝突的功能。
13. 性能的關鍵是精簡，而不是一堆的優化用例。除非有真正顯著的效果，否則一定要忍住你那些蠢蠢欲動的小微調的企圖。
14. 開發的越早，程序花費你的時間越長。
15. 原型的價值就在於它對你的教育，而不是代碼本身。
16. 進行軟件設計有兩種方式：一種是儘量讓它簡單，以至於明顯沒有任何缺陷。而另一種是儘量複雜，以至於找不到明顯的缺陷。
17. 醜陋的程序和醜陋的吊橋一樣：他們都容易坍塌，因爲人類（尤其是工程師們）的審美定義跟人們對複雜事物的處理和理解密切相關。一種編程語言如果不能使你寫出優美的代碼，那它也就不能使你寫出好的程序。
18. 使用一致的註釋風格
一些人堅信註釋應該寫到能被非編程者理解的程度，而其他的人則認爲註釋只要能被開發人員理解就行了。無論如何，Successful Strategies for Commenting Code已經規定和闡述了註釋的一致性和針對的讀者。就個人而言，我懷疑大部分非編程人員將會去閱讀代碼，因此註釋應該是針對其他的開發者而言。
19. 爲自己註釋代碼
當註釋代碼時，要考慮到不僅將來維護你代碼的開發人員要看，而且你自己也可能要看。用Phil Haack大師的話來說就是：“一旦一行代碼顯示在屏幕上，你也就成了這段代碼的維護者”。因此，對於我們寫得好(差)的註釋而言，我們將是第一個受益者(受害者)。