以下是節錄一些這本書覺得還不錯的點

• 激勵是有害的，主要是說考績制度對程式設計師是不通的
• 工作切換有害無益，讓程式設計師只專注一件事情
• 絕對不能把程式碼重寫（這裡不是指重構）
• 冰山一角理論，冰山有 90% 是在水面下，大部分的軟體，那些漂亮的使用者介面通常只占 10% 的工作，而背後 90% 的程式設是看不到的，如果再考慮一半時間都在抓蟲，那使用者介面就只剩 5%，如果只計算介面中的視覺部分，那客戶真正看到的，只有 1%……，這並不是秘密，真正的秘密是非程式人員根本不知道這件事……

約耳測試：

1. 你有使用原始碼控制系統嗎?？ SVN、CVS、Git、Mercurial…
2. 你能用一個步驟建出所有結果嗎？ 準備一個 Script 擋，只要執行這個腳本，就能一次搞定從最新原始碼快照到自動建立釋出產品的過程
3. 你有進行每日編譯嗎？ 提交原始碼到版本控制系統前，一定要編譯並且沒有出現錯誤，因為別人也想下班
4. 你有沒有問題資料庫？ 記錄已知的 Bug 清單，每筆 Bug 需記錄：
5. 重現問題的完整步驟
6. 應該看到的結果
7. 實際看到的結果
8. 被指派的負責人
9. 你會先把問題都修好之後，才寫新的程式嗎？ 愈晚修正問題，之後付出的代價成本愈高

你有一份最新的時程表嗎？ 程式設計師討厭排時程，但牽扯到業務人員的決策規劃，擁有時程可以強迫自己決定要作哪些功能，並剔除不重要的功能，以避免過度膨脹

1. 使用一些 PMS 工具
2. 時程表簡單就好
3. 每個功能應該包含多項任務（Task）
4. 只有實際要寫該程式的程式設計人員,才能排出該項目的時程
5. 要把任務分的很細（以小時為單位）
6. 紀錄最初和目前的估計
7. 每天更新已消耗時間
8. 把休假時間算進去
9. 把除錯時間算進去
10. 把整合時間算進去
11. 把緩衝時間算進去
12. 絕對不讓 PM 縮短估計時間

• 你有寫規格嗎？例如：GDD、TDD 又是一件程式設計師討厭的事情，設計初期的階段還看不出來，愈後期程式碼一多修正的代價就愈高，應貫徹沒有規格就不寫程式的原則
• 程式設計人員有沒有安靜的工作環境？ 需要讓程式設計師進入沈浸狀態（in the zone），因為這時候是最能全神貫注，生產力最高的狀態，所以，要有安靜的環境！！！
• 你有沒有用市面上最好的工具？ 你需要兩個以上的螢幕，以及編譯程式不會讓你抓狂的電腦配備
• 你有沒有測試人員？ 省下測試人員的錢並不是真正的節省，因為你會付出更慘痛的代價，這裡本書第 22 章有非常有趣的見解
• 是否在面試時要求面試的對象試寫程式？ 你會不請魔術師表演幾招就直接僱用他嗎，當然不會
• 是否進行過走廊使用性測試？ 隨機找幾位使用者試用你的產品，他們可以幫你發現程式中 95% 應該注意到的使用性問題

約耳認為軟體開發有各種不同的領域，他把它分為五個世界：

1. 熱縮封膜軟體（Shrinkwrap） 簡單來說就是一般常看到的軟體，商業軟體，共享軟體或開放源碼軟體等，特色就是使用者眾多，通常都有替代商品，所以開發者必須把東西做得更簡單易用才行
2. 內部用軟體 這類軟體通常是公司針對特定狀況下能執行就可以了，因此開發起來較容易，但開發者較不容易從中得到成就
3. 嵌入式軟體 這種軟體的特性是被放在硬體裡，且幾乎無法更新，因此品質要求會比平常高出許多
4. 拋棄式軟體 為了產生其他東西而暫時創造的軟體，當達到目的後就不會用到了，例如格式轉檔軟體
5. 遊戲軟體 遊戲開發的經濟學是打擊型，有些遊戲擊出安打，但更多的是三振，要賺大錢必須用很多的遊戲來平衡失敗的損失，和嵌入式軟體類似，版本修正代價大，所以品質要求高

• 紙上原型製作的重要性
• 別花太多時間想抽象的架構問題，邊開火邊移動！！！
• 寫程式並不是量產，也不是工匠技藝，它是一種設計

約耳認為面試人員應該問的問題：

1. 簡介
2. 最近專案的問題 尋找熱情 好的人選會仔細地把事情由各個層面解釋清楚 如果專案是由多個人一齊負責, 尋找擔任領導角色的跡象
3. 不可能的問題
4. 程式問題
5. 你有什麼問題嗎?

小員工也能做大事，這本書是關於軟體管理，不過有時候你並沒有那個權力去改變組織，如果你只是圖騰柱底層的一位程式設計人員，約耳給你一些建議：

1. 去做就是了 沒有每日編譯伺服器嗎？自己架一台就對了
2. 利用病毒性行銷的威力 團隊沒有在用版本管理系統？ 自己先用吧，等問題發生之後，他們就會來找你了
3. 建立一個卓越圈 找一些支持你的人一起改善吧
4. 讓笨蛋無害 有時候會有天才花兩個星期寫出一點點程式，而且爛到不可思議，這時候你會想花 15 分鐘把這段程式重新寫過，請忍住，因為這是把這個白癡拖住幾個月的機會，這段期間他不會再造成其他地方傷害了
5. 遠離干擾環境
6. 提升自己的價值