你失去的不只是一分鐘。
而是 23 分鐘。

在腦海中維持對程式碼庫的完整理解，其脆弱程度是其他大多數工作所沒有的。 針對開發者心流狀態的研究指出，一次注意力中斷後，要完全恢復最多需要 23 分鐘，而干擾本身平均每 3 到 10 分鐘就會發生一次。一項被 GitHub 引用的研究估計，會議、訊息和快速提問造成的頻繁打斷，可能抹去開發者高達 82% 的生產時間。

最常見的心流殺手不是會議，而是通知：Slack、電子郵件、行事曆提醒。 而且傷害不需要你做出回應。即使只是看到通知出現在螢幕上，就足以打斷專注力，就算你完全不去碰它。更廣泛來說，情境轉換已被證明會耗損一個人一天中約 40% 的生產時間。

大多數知識型工作都能容忍一定程度的碎片化。寫一封電子郵件、審閱一份文件，這些工作即使中斷五分鐘，損失也不大。 但程式設計完全不同，因為你腦中掌握的「狀態」沒有寫在任何地方，它是一個活生生的心智模型，包含變數狀態、呼叫堆疊，以及你正在推理的那個特定 bug 或功能。一次中斷不會暫停這個模型，而是直接抹除它，而那 23 分鐘就是花在重新建立這個模型上。

這就是為什麼「我只是快速看一下」對開發者來說，是比幾乎任何其他角色都更糟的交易。 快速查看本身可能只要十秒鐘。但它所摧毀的心智模型，卻需要 23 分鐘才能重建，如果在下一次干擾來臨前還重建得起來的話。

很多工程團隊在管理 Slack 噪音方面已經做得相當不錯：通知排程、批次站會、一天一場會議而不是三場。 關於會議頻率的研究也支持這個直覺：一天只開一場會議的團隊，有近 99% 的時間能維持每日目標的進度；但一旦加入第三場會議，這個數字就會掉到 14%。

但這些 Slack 紀律完全管不到放在鍵盤旁邊的那支手機。 一則簡訊、一個社群通知、一個遊戲更新，這些都會打斷和 Slack 一樣脆弱的心智模型，但它們通常不在任何團隊的專注時間政策範圍內，因為它們是私人的，而不是工作上的。

iOS 的專注模式可以在編寫程式時靜音通知，但應用程式仍然一鍵可達，而且靜音通知並不能阻止那種反射性的查看習慣。 在編譯之間或等待測試套件執行時瞥一眼手機的習慣，並不需要通知來觸發。

Fella 使用 Apple 的 Screen Time 框架，在 iPhone 層級封鎖所選的應用程式，所以即使在那些空檔時刻，也沒有什麼可以打開。 每次封鎖時段一次 5 分鐘的緊急解鎖足以應付真正的需求，而 Slack、電子郵件和工單系統等工作工具則可以全程保持不封鎖。

1. 封鎖那些與工作無關的應用程式。 社群媒體、遊戲和娛樂應用程式，讓 Slack、電子郵件和你的工單系統保持不封鎖。

2. 讓封鎖持續整個編寫工作日。 沒有可以在工單之間關閉的開關。

3. 把緊急解鎖用在真正重要的事情上。 每次封鎖時段的一次 5 分鐘緊急解鎖窗口，而不是編譯期間的滑手機時間。

4. 應用程式會自動重新鎖定。 下午四點在追蹤堆疊追蹤時，不需要靠意志力。