1. 程式設計師的工作切換成本#

Joel 將程式設計師的工作切換（Task Switching）類比為電腦的 Context Switch：當 CPU 在不同程序之間切換時，需要儲存與恢復暫存器狀態、重新載入快取，這些都是純粹的開銷——不做任何有用的計算，卻消耗了時間與資源。

人類的 context switch 成本遠比電腦嚴重：

• 進入「心流狀態（The Zone / Flow State）」通常需要 15 分鐘以上的不受打擾時間
• 一旦被中斷，之前建立的心智模型（程式碼結構、變數狀態、執行流程）會部分甚至完全瓦解
• 重新載入心智模型的成本，遠高於 CPU 重新載入暫存器的成本——因為人腦不支援「完美快照」

如果一位程式設計師每天被打斷 4 次，每次需要 15 分鐘恢復心流，那一天就損失了至少 1 小時的高品質工作時間。而實際損失往往更大，因為很多時候被打斷後根本無法回到之前的思路。

2. 為什麼中斷對程式設計師的傷害特別大#

不同職業對中斷的敏感度不同。程式設計師之所以特別脆弱，是因為他們的工作本質：

• 同時維持多層抽象：一位正在除錯的程式設計師，腦中可能同時處理演算法邏輯、資料結構狀態、API 介面、記憶體配置、多執行緒同步等多個層次的資訊
• 細節高度關聯：改動一行程式碼可能影響系統中看似無關的部分。維持這些關聯的心智模型需要專注力
• 錯誤的高成本：分心造成的疏忽可能引入微妙的 bug，這些 bug 可能在數週後才被發現，修復成本極高

2.1 中斷的常見來源#

• 同事的「快速問一下」（很少真的快速）
• 不相關的會議
• 即時通訊與電子郵件通知
• 被指派處理「緊急」但實際上不那麼緊急的事務
• 開放式辦公空間的噪音與視覺干擾

許多管理者低估中斷成本，是因為他們自己的工作模式本來就是以短暫互動為主。對管理者來說，一天開 8 個 15 分鐘的會議是正常的工作方式。但對程式設計師來說，這等於一整天都無法進入有效工作狀態。

3. 永遠不要讓一位程式設計師同時負責多個專案#

Joel 提出了一個明確的主張：永遠不要讓一位程式設計師同時被指派到多個專案。理由如下：

• 在兩個專案之間切換，不是簡單的「五五分」——實際上你得到的不是兩個各完成 50% 的專案，而是兩個各完成遠低於 50% 的專案
• 每次切換都需要重新載入另一個專案的全部心智上下文：程式碼架構、當前進度、待解決的問題、技術決策的脈絡
• 這種切換不只是浪費時間，更會降低思考的深度與品質

4. 管理者的責任：保護程式設計師的專注力#

Joel 認為，管理者最重要的工作之一，就是保護程式設計師免受不必要的中斷：

4.1 環境層面#

• 提供安靜的工作空間（最好是獨立辦公室或至少有門的空間）
• 建立「免打擾時段」的文化
• 減少不必要的全員會議

4.2 流程層面#

• 讓每位程式設計師在任何時間點只負責一個專案
• 用非同步溝通（如 email、issue tracker）取代打斷式的即時溝通
• 將問題彙整後批次處理，而非零星地逐一打擾

4.3 文化層面#

• 讓整個團隊理解專注力的價值
• 不以「隨時可聯繫」作為評價標準
• 尊重「我現在正在專注工作，稍後回覆」的回應

一個簡單的測試：觀察你的程式設計師每天有多少段不被打斷的 2 小時以上的時間。如果答案是零，你的團隊幾乎不可能產出高品質的程式碼。

5. 單一任務制的威力#

當一位程式設計師能專注在單一任務上時，會產生一系列正向效果：

• 更深入的思考：有足夠的心智空間去考慮邊界條件、效能最佳化、程式碼可維護性
• 更少的 bug：專注的工程師犯的錯誤更少
• 更快的完成速度：看似矛盾，但專注做一件事比同時做多件事更快完成所有事
• 更高的工作滿足感：完成一件有深度的工作帶來的成就感，遠大於在多個專案之間疲於奔命

許多組織試圖透過讓工程師「多工」來提高「資源利用率」。這種思維把人當成機器——但即使是機器，context switch 也有成本。人類的 context switch 成本比機器高出幾個數量級。追求 100% 的「資源利用率」，結果往往是接近 0% 的「有效產出率」。