1、關心你的技藝
Care About Your Craft
除非你在乎能否漂亮地開發出軟件，否則其它事情都是沒有意義的。
2、思考！你的工作
Think!About Your Work
在你做某件事情的時候思考你在做什么。不間斷地思考，實時地批判你的工作。這將占據你的一些寶貴時間，酬勞則是更為活躍地參與你喜愛的工作、感覺到自己在掌握范圍日增的各種主題以及因感受到持續的進步而歡愉。從長遠來說，你在時間上的投入將會隨著你和你的團隊變得更為高效、編寫出更易于維護的代碼以及開會時間的減少而得到回報。
3、提供各種選擇，不要找蹩腳的借口
Provide Options,Don't Make Lame Excuses
不要說事情做不到；要說明能夠做什么來挽回局面。不要害怕提出要求，也不要害怕承認你需要幫助。
4、不要容忍破窗戶
Don't Live With Broken Windows
不要留著“破窗戶”（低劣的設計、錯誤的決策、或者糟糕的代碼）不修。發現一個就修一個。如果沒有足夠的時間進行適當的修理，采取某種行動防止進一步的破壞，并說明情勢處在你的控制之下。
如果你發現你所在團隊和項目的代碼十分漂亮——編寫整潔、設計良好，并且很優雅，你不會想成為第一個弄臟東西的人。
5、做變化的催化劑
Be a Catalyst for Change
你不能強迫人們改變。相反，要向他們展示未來可能會怎樣，并幫助他們參與對未來的創造。
設計出你可以合理要求的東西，好好開發它。一旦完成，就拿給大家看，讓他們大吃一驚。然后說：“要是我們增加...可能就會更好。”假裝那并不重要。坐回椅子上，等著他們開始要你增加你本來就想要的功能。人們發現，參與正在發生的成功要更容易。讓他們瞥見未來，你就能讓他們聚集在你周圍。
6、記住大圖景
Remember the Big Picture
如果你抓一只青蛙放進沸水里，它會一下子跳出來。但是，如果你把青蛙放進冷水里，然后慢慢加熱，青蛙不會注意到溫度的緩慢變化，會呆在鍋里，直到被煮熟。
不要像青蛙一樣。留心大圖景。要持續不斷地觀察周圍發生的事情，而不只是你自己在做的事情。
7、使質量成為需求問題
Make Quality a Requirements Issue
你所制作的系統的范圍和質量應該作為系統需求的一部分規定下來。讓你的用戶參與權衡，知道何時止步，提供足夠好的軟件。
8、定期為你的知識資產投資
Invest Regularly in Your Knowledge Portfolio
讓學習成為習慣。
持續投入十分重要。一旦你熟悉了某種新語言或新技術，繼續前進，學習另一種。
是否在某個項目中使用這些技術，或者是否把它們放入你的簡歷，這并不重要。學習的過程將擴展你的思維，使你向著新的可能性和新的做事方式拓展。思維的“異花授粉”十分重要；設法把你學到的東西應用到你當前的項目中。即使你的項目沒有使用該技術，你或許也能借鑒一些想法。例如，熟悉了面向對象，你就會用不同的方式編寫純C程序。
如果你自己找不到答案，就去找出能找到答案的人。不要把問題擱在那里。
9、批判地分析你讀到的和聽到的
Critically Analyze What You Read and Hear
不要被供應商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對信息進行分析。
10、你說什么和你怎么說同樣重要
It's Both What You Say and the Way You Say It
作為開發者，我們必須在許多層面上進行交流。我們的時間有很大部分都花在交流上，所以我們需要把它做好。
如果你不能有效地向他人傳達你的了不起的想法，這些想法就毫無用處。
知道你想要說什么；了解你的聽眾；選擇時機；選擇風格；讓文檔美觀；讓聽眾參與；做傾聽者；回復他人。
交流越有效，你就越有影響力。
11、DRY原則——不要重復你自己
DRY - Don't Repeat Yourself
系統中的每一項知識都必須具有單一、無歧義、權威的表示。與此不同的做法是在兩個或更多地方表達同一事物。如果你改變其中一處，你必須記得改變其它各處。這不是你能否記住的問題，而是你何時忘記的問題。
12、讓復用變得容易
Make it Easy to Reuse
你要做的是營造一種環境，在其中要找到并復用已有的東西，比自己編寫更容易。如果復用很容易，人們就會去復用。而如果不復用，你們就會有重復知識的風險。
13、消除無關事物之間的影響
Eliminate Effects Between Unrelated Things
我們想要設計自足（self-contained）的組件：獨立，具有單一、良好定義的目的。如果組件是相互隔離的，你就知道你能夠改變其中一個，而不用擔心其余組件。只要你不改變組件的外部接口，你就可以放心：你不會造成波及整個系統的問題。
你得到兩個主要好處：提高生產率與降低風險。
14、不存在最終決策
There Are No Final Decisions
沒有什么永遠不變——而如果你嚴重依賴某一事實，你幾乎可以確定它將會變化。與我們開發軟件的速度相比，需求、用以及硬件變得更快。通過DRY原則、解耦以及元數據的使用，我們不必做出許多關鍵的、不可逆轉的決策。有許多人會設法保持代碼的靈活性，而你還需要考慮維持架、部署及供應商集成等領域的靈活性。
15、用曳光彈找到目標
Use Tracer Bullets to Find the Target
曳光彈能通過試驗各種事物并檢查它們離目標有多遠來讓你追蹤目標。
曳光彈代碼含有任何一段產品代碼都擁有的完整的錯誤檢查、結構、文檔、以及自查。它只不過功能不全而已。但是，一旦你在系統的各組件之間實現了端到端（end-to-end）的連接，你就可以檢查你離目標還有多遠，并在必要的情況下進行調整。一旦你完全瞄準，增加功能將是一件容易的事情。
16、為了學習而制作原型
Prototype to Learn
任何帶有風險的事物。以前沒有試過的事物，或是對于最終系統極其關鍵的事物。任何未被證明的、試驗性的、或有疑問的事物。任何讓你覺得不舒服的東西。都可以通過制作原型來研究。比如：架構；已有系統中的新功能；外部數據的結構或內容；第三方工具或組件；性能問題；用戶界面設計等等。
原型制作是一種學習經驗，其價值并不在于所產生的代碼，而在于所學到的經驗教訓。
17、靠近問題領域編程
Program Close to The Problem domain
計算機語言會影響你思考問題的方式，以及你看待交流的方式。用你的用戶的語言進行設計和編碼。
18、估算，以避免發生