寫程式 (Coding) #
寫出一份合格程式碼並不容易，它須同時滿足：正常運作、解決問題、與系統整合、且好讀易懂。
為達這高標準，專業人士須嚴格管理自己的精神狀態。
1. 保持精準的專注力 #
⛔ 疲勞時絕不寫程式 #
當你疲勞、心煩意亂或注意力分散時，產出的程式碼往往是垃圾，最後你得花更多時間去修補它。
專業人士會選擇停下來休息，而不是硬撐。
⚠️ 警惕「心流 (Flow)」狀態 #
許多程式設計師喜歡進入「心流」狀態（那種忘我、時間飛逝的感覺），但作者提出了反直覺的警告：別刻意追求心流。
| 維度 | 核心觀點 | 影響與建議細節 |
|---|---|---|
| 潛在風險 | 管窺效應 (Tunnel Vision) | 心流可能導致過度專注於局部細節，進而迷失系統大局觀 (Big Picture) |
| 外部干擾 | 音樂的影響 | 音樂易誘發心流並消耗部分腦力；作者建議寫程式時盡量不聽音樂以維持警覺 |
| 解決對策 | 結對程式設計 (Pair) | 透過對話與互動打破單人沉迷，強迫大腦切換視角，保持對整體的覺察 |
應對干擾與卡關 #
- 接受打斷：工作中被打斷是常態。若你有用 TDD (測試驅動開發) 或結對程式設計，你能迅速找回剛才的進度
- 疏通思緒 (Writer’s Block)：寫不出程式通常源於睡眠不足或負面情緒（焦慮、恐懼）
- 解法：找人結對（讓隊友幫你重啟思路）、或暫時轉換跑道去閱讀其他主題的書籍，讓外來創意激發靈感
2. 節奏與除錯 #
減少除錯時間 (Debugging) #
花費大量時間在除錯上，並非專業表現。
- 專業標準：製造 Bug 的開發者並不專業
- 解決方案：全面採用 TDD。當測試覆蓋率夠高，你的除錯時間應趨近於零
長跑心態 #
軟體開發是場馬拉松，不是短跑。
- 保留體力：疲倦時就休息。創意和智力依賴於大腦的高速運轉，過勞腦袋產不出好東西
- 善用離線時間：洗澡、開車或通勤時，暫時抽離鍵盤。讓大腦的背景程序運作，往往能在這些時刻迸發出創意的解決方案
3. 進度管理：誠實與預估 #
儘早告知延遲 #
如果你預感進度會落後，請儘早告知團隊與利害關係人。最糟糕的情況是給予對方錯誤期望。
三元預估法 (PERT) #
不要只給一個單一日期，用三個數值描述不確定性：
| 預估類型 | 核心情境描述 | 發生機率與特性 | 應用考量 |
|---|---|---|---|
| 樂觀預估 (Optimistic) | 假設開發過程中一切順利，無任何突發阻礙 | 極低；僅具備理論上的參考價值 | 用於標記最佳路徑 |
| 常規預估 (Nominal) | 綜合考量目前資源與現狀，認為最可能發生的情況 | 最高；作為主要進度規劃的基礎 | 用於對齊團隊進度 |
| 悲觀預估 (Pessimistic) | 考慮到風險、技術負債或發生意外時的應變情況 | 中等；包含緩衝時間以應對不確定性 | 用於風險控管與承諾 |
期望管理： 當「常規預估」已超過「計畫期限」，你就必須誠實告知任務不可能如期完成，別讓老闆抱有幻想。
關於「衝刺」與加班 #
作者認為「快速衝刺」通常是種幻想，我們很難單純透過加快打字速度來解決問題。
但在極端情況下，若必須加班，需滿足三個條件：
| 判斷準則 | 前提條件 | 細節與風險控管 |
|---|---|---|
| 個人可行性 | 時間能擠出 | 評估個人體力與時間是否確實足以負荷額外的工作量 |
| 時效控制 | 短期戰役 | 加班必須設定明確終點，最多維持兩週，以避免身心崩潰與效率斷崖 |
| 風險轉嫁 | 老闆有備案 | 管理階層必須備妥 Plan B，確保萬一加班仍無法達成目標時有應對措施 |
4. 交付與協作 #
定義「完成 (Done)」 #
什麼時候才算寫完？不是「我寫好了」，而是：
- 通過驗收測試：請業務分析師和測試人員協助建立「自動化驗收測試」。只有程式碼通過這些測試，才算真正完成
- 絕不交付失敗成果：如果你允許低品質的交付（即便只有一次），之後的標準只會越來越低
互助的藝術 #
程式設計很難，我們需要將複雜系統分解為小單元，這需要集體智慧。
- 以助人為榮：幫助別人解決問題，同時也獲得新視角
- 接受幫助：這不是天生習慣，需要團隊紀律來驅動
- 輔導責任：資深人員須花時間輔導年輕同仁，這是你的專業職責，而非額外施捨
補充：為什麼要輔導？
在學校我們習慣單打獨鬥爭取分數，但在職場，團隊的總體產出才是關鍵。
資深工程師的價值不只在於自己的產出，更在於提升整個團隊水位。