1.做事。指責不會修復BUG。把矛頭對準問題的解決辦法，而不是人。這是真正有用處的正面效應。把重點放到解決問題上，而不是指責犯錯者，或者去抱怨。“爲了解決或緩解這個問題，我能夠做什麼？”、“你出現了什麼問題，我能提供什麼樣的幫助？”。
2.欲速則不達。不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。如果時間緊迫，可以簡單修復，但是簡單修復之後要明其理，時間充裕時，要修改。必須理解一塊代碼是如何工作的，不要急於修復一段沒能真正理解的代碼。不要孤立地編碼，同時也要理解協作成員的代碼。使用單元測試可以更深入的理解、運行和使用代碼。
3.對事不對人。在團隊協作中，禮貌對待他人，有益於整個團隊關注真正有價值的問題。負面的評論和態度會扼殺創新。設定最終期限，可以讓人在爲難的時候果斷作出決策。逆向思維，先積極的看到他的正面，然後再努力地從反面去認識。設立沒有利益關係的仲裁人。支持已經作出的決定，一旦確立，通力合作實現之。讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好。“我想知道，如果XXX會發生什麼情況？”。
4.排除萬難，奮勇前進。要誠實，要有勇氣去說出實情。有時，這樣做很困難，所以我們要有足夠的勇氣。“我現在知道了，我過去使用的方法不對。我想到了一些辦法，可以解決這個問題——如果你有更好的想法，我也很樂意聽一聽——但可能會花多些時間。”重寫糟糕的代碼，降低維護成本。“別管他媽的什麼魚雷，全速前進”。
5.跟蹤變化。你不需要精通所有技術，但需要清除知道行業的動向，從而規劃你的項目和職業生涯。迭代和增量式的學習，每天計劃用一段時間來學習新技術。瞭解最新行情，學習優秀的技術博客。參加本地的用戶組活動。參加研討會議。如飢似渴地閱讀，軟件開發和非技術主題的好書。
6.對團隊投資。提供你和團隊學習的更好平臺。通過午餐會議可以增進每個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對項目大有裨益。
7. 懂得丟棄。學習新的東西，丟棄舊的東西。在學習一門新技術的時候，要丟棄會阻止你前進的就習慣。畢竟，汽車要比馬車車廂強得多。變化是永恆的，首先要意識到你使用的方法是過時的，果斷丟棄就習慣。新技術會讓人感到有一點恐懼。你確實需要學習很多東西。已有的技能和習慣爲你打下了很好的基礎，但不能依賴他們。
8.打破砂鍋問到底。爲了解決問題你需要很好的瞭解系統的全局。要問至少5個爲什麼。爲什麼會問呢？因爲我不知道。不停的問爲什麼。不能只滿足於別人告訴你的表面現象。要不停的問直到你明白問題的根源。
9.把握開發節奏。設定一個短時的期限，爲任務設定不能延長的最終期限。你可以改變功能但是不能改變時間。項目開發需要有一致和穩定的節奏。編輯，運行測試，代碼複審，一致的迭代，然後發佈。如果知道什麼時候開始下一個節拍，跳舞就會更加容易。
10.讓客戶做決定。開發者、經理或業務分析師不應該做業務方面的決定。用業務負責人能理解的語言，向他們詳細解釋遇到的問題，並讓他們做決定。當和客戶討論問題的時候，準備幾種可選擇的方案。不是從技術的角度，而是從業務的角度，介紹每種方案的優缺點，以及潛在的成本和利益。和他們討論每個選擇對時間和預算的影響以及如何權衡。
11.讓設計指導而不是操縱開發。設計滿足現實即可，不必過於詳細。好的設計是一張地圖，它也會進化。設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計操縱。在沒有經過真正的代碼驗證之前，不要陷入太多的設計任務。設計是沒有價值的，但設計的過程是必不可少的。深入理解需求後進行戰略設計，但不要深入到具體的細節。
12.合理地使用技術。首先需要對你使用的技術進行一下幾方面的評估：這可技術框架是否真能解決這個問題；是否會被這個技術拴住；維護的成本是多少。所選擇的技術一定是真正適合你的項目的，不要被它零碎的功能所吸引。不要開發你能下載到的東西。因爲你的代碼寫得越少，需要維護的東西就越少。根據需要來選擇技術。新技術就應該像是新的工具，可以幫助你更好的工作，它自己不應該成爲你的工作。
13.保持可以發佈。在團隊裏工作，修改一些東西的時候必須很謹慎。你要時刻警惕，每次改動都會影響系統的狀態和整個團隊的工作效率。在本地運行測試，先保證你完成的代碼可以編譯，並且能通過所有的單元測試，接着確保系統中的其他測試都可以通過。檢出最新的代碼，從版本控制系統中更新代碼到最新的版本，再編譯運行和測試。提交代碼。保持你的項目時刻可以發佈。保證你的系統隨時可以編譯、運行、測試並立即部署。你的項目應該一直處於可以運行的穩定狀態。
14.提早集成，頻繁集成。提早集成可以更容易的發現系統的風險。集成和獨立不是相互矛盾的，可以一邊集成一邊進行獨立開發。代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。絕不要做大爆炸式的集成。
15.提早實現自動化部署。能用一種可重複和可靠的方式，在目標機器上部署你的應用。質量保證人員應該測試部署過程。提早實現自動化部署，既可以測試應用，又可以測試安裝過程。一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置文件測試依賴的問題。質量保證人員要像測試應用一樣測試部署。
16.使用演示獲得頻繁反饋。在項目開始之前你是無法得到可靠和明確的需求，需求是時刻變化的。軟件開發的成功就在於最後你離客戶的期望有多近。頻繁的演示可以使你付出很少的代價，就可以避免災難。需要項目術語表，可以減少團隊成員之間和客戶之間的歧義。清晰可見的開發。在開發的時候要保持應用可見。每隔一週或者兩週，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。還要建立項目跟蹤日誌，包括：修正、建議、變更要求、功能增強和bug修復等。做到這些，首先要注重客戶的時間，其次缺少功能和穩定性的時候，不應該拿來演示，那隻能讓人生氣。
17.使用短迭代，增量發佈。統一過程和敏捷方法都使用迭代和增量開發。每一次開發都是基於前一次的功能。迭代開發是，在小且重複的週期裏，你完成各種開發任務：分析、設計、實現、測試和獲得反饋，所以叫做迭代。對付大項目，最理想的辦法就是小步前進，這也是敏捷方法的核心。大步跳躍大大的增加了風險，小步前進纔可以幫助你很好地把握平衡。使用短迭代和增量開發，可以讓開發者更加專注於自己的工作。增量開發。發佈帶有最小可用功能塊的產品。每個增量開發中，使用1-4周左右迭代週期。短迭代讓人感覺非常專注且具有效率。你能看到一個實際並且確切的目標。嚴格的最終期限迫使你做出一些艱難的決策，沒有遺留下長期懸而未決的問題。
18.固定的價格就意味着背叛承諾。主動提議先構建系統最初的、小的、和有用的部分，足夠一次交付，並能讓用戶真正使用。第一個迭代結束時客戶有兩個選擇：可以選擇一些列新的功能，繼續進入下一個迭代；或者取消合同，僅需支付第一個迭代的費用。如果繼續，預測下一個迭代的工作，給他們同樣的選擇機會。對客戶的好處是：項目不可能會死亡，很早的看到工作進度或不足之處，總是可以控制項目，可以隨時停止，不需繳納任何違約金。可以控制先完成哪些功能，並精確地知道需要花費哪些資金。客戶承擔的風險會很低。
19.守護天使。編寫能產生反饋的代碼。確保測試是可重複的，測試你的邊界條件，不要放過任何一個失敗的測試。單元測試的作用：單元測試能及時提供反饋；單元測試讓你的代碼更加健壯；單元測試是有用的設計工具；單元測試是讓你自信的後臺；單元測試是解決問題時的探測器；單元測試是可信的文檔；單元測試是學習的工具。使用自動化的單元測試。好的單元測試能夠爲你的代碼問題提供及時的報警。如果沒有到位的單元測試，不要進行任何設計和代碼修改。
20.先用它再實現它。使用TDD（測試驅動開發）的技術，在編程之前，先寫測試。就會使你站在用戶的角度來思考，而不僅僅單純是一個實現者。因爲你自己要使用它們，所以能設計一個更有用、更一致的接口。先寫測試有助於消除過度複雜的設計，讓你專注於真正需要完成的工作。TDD有機會讓你編寫代碼之前，可以讓你深思熟慮將如何用它。迫使你思考它的有用性和便利性，並讓你更加註重實效。設計不是在開始編碼的時候就結束了。你需要在它的生命週期中持續地添加測試，添加代碼，並重新設計代碼。
21.不同環境就有不同問題。我們需要更加面向開發者的測試辦法。除了單元測試、測試用例外，我們所要做的就是在各種支持的平臺和環境中運行這些測試用例。不同環境就有不同問題。使用持續集成工具，在每一種支持的平臺和環境中運行單元測試。要積極地尋找問題，而不是等問題來找你。
22.自動驗收測試。要使驗收測試不同於單元測試。應該讓用戶在不必學習編碼的情況下，根據自己的需要進行添加、更新和修改數據。如果領域的專家提供了業務的算法、運算或者方程式，爲他們實現一套可以獨立運行的測試。要讓這些測試都成爲測試套件的一部分，不會在項目生命週期中確保持續爲它們提供正確的答案。爲核心的業務邏輯創建測試。讓你的客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動運行。
23.度量真實的進度。判斷工作的進度最好是看實際花費的時間而不是估計的時間。我們不應該去計算工作量的百分比，而應該測定還剩下多少工作量沒有完成。在你最後真正完成一項任務時，要清除知道完成這個任務真正花費的時間。作爲下一次的參考，使評估與事實接近，對任務所花費的時間有更清楚的認識。爲了使下一步工作是可見的，使用辦事項（backlog）。添加新任務要考慮優先級。清楚項目的真實進度，是一項強大的技術。度量剩下的工作量。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。關注功能而不是日程表。
24.傾聽用戶的聲音。不管它是否是產品的bug，還是文檔的bug，或者是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。我們花費了很大的精力從單元測試之類的代碼中獲得反饋，但卻容易忽略最終用戶的反饋。你不僅需要和真實的用戶交談，還需要耐心地傾聽。對客戶的那些抱怨，既不要輕視，也不要生氣。你應該查看一下，找出背後真正的問題。
25.代碼要清晰地表達意圖。開發代碼時，應該更注重可讀性。實際上，從衡量標準上來看，代碼清晰程度的優先級應該排在執行效率之前。在改動代碼以修復bug或者添加新功能時，首先應該理解代碼做了什麼，它是如何做的。接下來，搞清楚將要改變哪些部分，然後着手修改並進行測試。同時也應該注意，註釋有時是爲了幫寫的不好的代碼修補漏洞。好的編碼規範可以讓代碼變的易於理解，同時減少不必要的註釋和文檔。
26.用代碼溝通。不要用註釋來包裹你的代碼。源代碼被讀懂，不是因爲其中的註釋，而應該是由於它本身優雅而清晰——變量名運用正確、空格使用得當、邏輯分析清晰，以及表達式非常簡潔。代碼被閱讀的次數要遠超過被編寫的次數，所以在編程時多付出一點努力來做好文檔，會讓你在將來受益匪淺。使用細心選擇的、有意義的命名。用註釋描述代碼意圖和約束。註釋不能替代優秀的代碼。
27.動態評估取捨。動態評估權衡。考慮性能、便利性、生產力、成本和上市時間。如果性能表現足夠了，就將注意力放在其它因素上。不要爲了感覺上的性能提升或者設計的優雅，而將設計複雜化。提升千分之一的性能遠不及節約成本和時間，儘早上市更有意義。
28.增量式編程。增量式編程可以精煉並結構化你的代碼。在重構的原則指導下，可以做出許多細微改善。在很短的編輯/構建/測試循環中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好很多。可以創建更加清晰、簡單、易於維護的代碼。
29.保持簡單。開發人員更應該爲自己能夠創建出一個簡單並且可用的設計而驕傲。簡單並不意味着簡陋、業餘或者是能力不足。優雅的代碼第一眼看上去，就知道它的用處，而且很簡潔。但是這樣的解決方案不是那麼容易想出來的。這就是說，優雅是易於理解和辨識的，但是要想創建出來就困難多了。簡單、可讀性強纔是好的代碼。
30.編寫內聚的代碼。內聚性用來評估一個組件中成員的相關性。內聚程度高，表明各個成員共同完成了一個功能或者是一組功能特性。內聚性會影響一個組件的可重用性。讓類的功能儘量集中，讓組件儘量小。要避免創建很大的類或者組件，也不要創建無所不包的大雜燴類。每個類和組件只做一件事。
31.告知，不要詢問。面向過程的代碼取得信息，然後做出決策。面向對象的代碼讓別的對象去做事情。與告知，不要詢問相關的一個很有用的計數是：命令與查詢相分離的模式，就是將功能和方法分爲“命令”和“查詢”兩類。一個常規的“命令”可能會改變對象的狀態，而且有可能返回一些有用的值，以方便使用。一個“查詢”僅僅提供給開發人員對象的指針狀態，並不會對其外部的可見狀態進行修改。告知，不要詢問感覺起來就像你在發送消息，而不是調用函數。
32.根據契約進行替換。
33.記錄問題解決日誌。包含以下條目：問題發生日期；問題簡述；解決方案詳細描述；引用文章或網址，以提供更多細節或者相關信息；任何代碼片段、設置或對話框的截屏，只要他們是解決方案的一部分，或者可以幫助更深入地理解相關細節。