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

在脑海中维持对代码库的完整理解，其脆弱程度是其他大多数工作所没有的。 针对开发者心流状态的研究指出，一次注意力中断后，要完全恢复最多需要 23 分钟，而干扰本身平均每 3 到 10 分钟就会发生一次。一项被 GitHub 引用的研究估计，会议、信息和快速提问造成的频繁打断，可能抹去开发者高达 82% 的生产时间。

最常见的心流杀手不是会议，而是通知：Slack、电子邮件、日历提醒。 而且伤害不需要你做出回应。即使只是看到通知出现在屏幕上，就足以打断专注力，就算你完全不去碰它。更广泛来说，情境转换已被证明会损耗一个人一天中约 40% 的生产时间。

大多数知识型工作都能容忍一定程度的碎片化。写一封电子邮件、审阅一份文档，这些工作即使中断五分钟，损失也不大。 但程序设计完全不同，因为你脑中掌握的「状态」没有写在任何地方，它是一个活生生的心智模型，包含变量状态、调用堆栈，以及你正在推理的那个特定 bug 或功能。一次中断不会暂停这个模型，而是直接抹除它，而那 23 分钟就是花在重新建立这个模型上。

这就是为什么「我只是快速看一下」对开发者来说，是比几乎任何其他角色都更糟的交易。 快速查看本身可能只要十秒钟。但它所摧毁的心智模型，却需要 23 分钟才能重建，如果在下一次干扰来临前还重建得起来的话。

很多工程团队在管理 Slack 噪音方面已经做得相当不错：通知排程、批量站会、一天一场会议而不是三场。 关于会议频率的研究也支持这个直觉：一天只开一场会议的团队，有近 99% 的时间能维持每日目标的进度；但一旦加入第三场会议，这个数字就会掉到 14%。

但这些 Slack 纪律完全管不到放在键盘旁边的那支手机。 一则简讯、一个社群通知、一个游戏更新，这些都会打断和 Slack 一样脆弱的心智模型，但它们通常不在任何团队的专注时间政策范围内，因为它们是私人的，而不是工作上的。

iOS 的专注模式可以在编写代码时静音通知，但应用仍然一键可达，而且静音通知并不能阻止那种反射性的查看习惯。 在编译之间或等待测试套件执行时瞥一眼手机的习惯，并不需要通知来触发。

Fella 使用 Apple 的屏幕使用时间框架，在 iPhone 层级屏蔽所选的应用，所以即使在那些空档时刻，也没有什么可以打开。 每次屏蔽时段一次 5 分钟的紧急解锁足以应付真正的需求，而 Slack、电子邮件和工单系统等工作工具则可以全程保持不屏蔽。

1. 屏蔽那些与工作无关的应用。 社交媒体、游戏和娱乐应用，让 Slack、电子邮件和你的工单系统保持不屏蔽。

2. 让屏蔽持续整个编写工作日。 没有可以在工单之间关闭的开关。

3. 把紧急解锁用在真正重要的事情上。 每次屏蔽时段的一次 5 分钟紧急解锁窗口，而不是编译期间的滑手机时间。

4. 应用会自动重新锁定。 下午四点在追踪堆栈追踪时，不需要靠意志力。