“心流状态”，一种专注到忘我的工作状态——正处于激烈的争论之中。

一方面，开发者们经常为保护工作流程而奋战，抵制会议和 Slack 消息的干扰。另一方面，管理者和同事们出于各种原因打断开发者，他们往往低估了这些打断的成本。

在开始写作这篇文章之前，我以为情况很简单：开发者们需要时间和空间进入心流状态，一旦进入这种状态，他们的工作效率就会最高。

诚然，打断开发工作的理由有很多——高优先级的漏洞、重要的校准会议、突发事件等等，但除此之外，对于公司和开发团队来说，似乎理所当然应该优化工作流程，减少干扰，增加专注力。

毕竟，公司雇佣开发者不就是为了让他们进行开发工作的吗？让他们分心于其他事情岂不是本末倒置？

然而，在过去几周内，我阅读了十几篇关于心流状态和开发者生产力的论文。事实证明，心流状态的细微差别比我想象的要复杂得多，我之前那种非黑即白的理解过于简单。

几乎所有人，事实证明，都对心流状态存在误解。

当我想到开发者和心流状态时，我(和其他许多人一样)会想到 Jason Heeris 的这幅漫画。

漫画中，一位开发者正在面对一个问题，并逐步构建解决方案的框架。突然，一位同事走过来，说：“嗨，我刚给你发了一封关于那件事的电子邮件。” 开发者的思绪瞬间被打断。同事吹着口哨走开了，开发者则重新回到屏幕前，但问题仍然没有解决——之前的所有进展都消失了。

十多年前创作的这幅漫画之所以引起共鸣，是因为它确实反映了开发者们普遍的经历。但是，当我们如此简单地概括这种体验时，我们错过了什么呢？这正是我着手学习的内容。

心流状态的起源

Mihaly Csikszentmihalyi，一位匈牙利裔美国心理学家，因其在 20 世纪 70 年代关于心流状态的开创性研究而被称为“心流之父”。

然而，这项研究最初的重点并不是单纯的专注力，也不是解决复杂问题的认知负荷。Csikszentmihalyi 最感兴趣的是弄清楚人们在什么时候以及如何能够在工作中不需要思考或反思所做的事情的情况下进行工作。

现在，“心流状态”有着各种各样的关联——一些是科学的，一些是大众的，还有一些两者兼而有之。对许多人来说，这个术语只不过是专注的另一种说法。

根据 Csikszentmihalyi 最初的定义，心流状态与复杂的解决问题几乎没有关系。他最初的灵感来自画家们，他说画家们会“完成一件艺术作品，却没有去欣赏它……而是把它靠在墙上，然后开始创作另一幅画。”

他意识到，画家们的驱动因素并不是绘画本身，而是进入、保持和享受他最终称之为“心流状态”的东西。

在随后的 1980 年代和 1990 年代，一系列的研究问世，使这个概念逐渐为公众所理解。

除了艺术之外，许多对心流状态最感兴趣的人都是运动员。例如，达拉斯牛仔队在 1993 年赢得超级碗比赛之后，主教练吉米·约翰逊 (Jimmy Johnson) 称赞了 Csikszentmihalyi 关于心流状态的著作，并表示：“我的球队之所以获胜，正是因为这本书。”

2000 年，Malcolm Gladwell 写了一篇文章，分析了职业网球运动员 Jana Novotna 在温网比赛中“崩溃”的原因。他的观点是：Novotna 没有维持住心流状态。

起初我感到惊讶，但这说得通。

艺术和运动都涉及到大量灵巧的身体动作，我可以理解为什么这些领域的专业人士会受益于学习如何抵抗过度思考，从而能够“只管去做”。

然而，几乎每个职业都需要一定程度的专注，所以你可以理解，随着时间的推移，流状态的概念已经超越了其原始的限制。 现在，“流状态”有各种各样的联想——一些是科学的，一些是民间的，一些是两者的混合。对许多人来说，这个术语只不过是专注的一个装饰性版本。

我通常不会对一个术语过于苛刻。但随着我阅读越来越多的研究资料，并与越来越多的开发者交谈，我越来越觉得，我们对心流状态的简化定义让我们失去了一些最初使这个概念如此流行的丰富内涵。

心流状态之所以流行，主要是因为它的功能和感受。但是，过于强调“处于心流状态”的感觉可能会让我们忽视真正应该做的事情。我们知道，最有影响力的开发工作无法用代码行来衡量，但我们仍然可能会过度强调心流状态，并与所有干扰——无论它们是打破专注力还是与专注力一致——进行斗争。

最大的威胁不是外部干扰，而是内部的碎片化

换句话说，心流状态——在理想状态下是一种通往富有成效和创造性目的的手段——可能会变成目的本身。

例如，一个高优先级的漏洞值得被中断。失去的注意力可能是值得的权衡。然而，这些“值得的干扰”并不局限于会议。

心流状态研究的核心发现之一是，人们要想进入心流状态，需要的不仅仅是专注力。在下图中，例如，你可以看到只有技能和挑战的特定匹配才能导致心流状态。

你可能专注于开发，但如果特定的任务在情感上具有挑战性，同时需要很少的技能，你可能只是警觉和专注。同样，如果你的当前工作需要大量的技能，但很少有挑战，你可能会感到掌控和自信，但不会处于心流状态。换句话说，心流状态的条件可能并不总是具备的。

我阅读得越多，就越意识到我们所有人都需要升级对心流状态的思考。在 Csikszentmihalyi 的最初研究之后的几十年里，已经有数十项关于开发者工作方式的研究。

例如，一项 2023 年的研究发现，阻碍心流状态的因素有很多——其中许多因素不仅仅是来自同事的干扰。研究人员将这些因素归类为情境障碍(例如，干扰和分心)、个人障碍(例如，工作过于具有挑战性或不够具有挑战性)以及人际障碍(例如，管理不善和团队动态不佳)。

此外，一项 2018 年的研究发现，最具破坏性的干扰不是外部的，而是内部的。81% 的参与者预测内部干扰会更糟，但他们错了。研究人员写道：“自我干扰会使任务切换和干扰更加具有破坏性，因为它们会负面影响暂停期的时间和嵌套干扰的数量。”

这两项研究，以及我为了找到这两项研究而阅读的十几项研究，让我有了这样一个理论。阻碍心流状态的因素有很多，但最糟糕的阻碍和最糟糕的干扰是内部的，这意味着开发工作流程本身需要改进。

最大的威胁不是外部干扰，而是内部的碎片化——开发者允许自己为了重要但最终会分散注意力的任务而暂停心流状态。

好消息是：在保持心流状态方面，我们比我们想象的更有力量。坏消息是：我们可能需要放手让那些带着愚蠢问题的同事们(至少稍微放手)。

为什么碎片化思维是开发者的隐形杀手

我开始研究这个问题，不是为了提高开发者的生产力，而是为了看看那些认为自己在专注的开发者是否真的取得了成功。我担心，“心流状态”在开发者中的流行导致许多开发者认为，关闭 Slack 通知或封锁他们的日历就是他们所能做的全部。

现实生活中的碎片化思维

我并不是想过于批评开发者对心流状态的普遍假设。例如，Jason Heeris 的那幅著名的漫画捕捉了一个有用的真相。

漫画说明了问题不仅仅是重新开始工作或返回正在进行的任务。中断会打破心流状态，并迫使开发者重新启动解决面前问题所需的复杂系统思维。

考虑到这一点，你可以理解为什么自愿的自我干扰可能比外部干扰更糟。你正在完全将你的思维从一个任务转移到另一个任务上——确保心流状态和你的大脑保持着的高层次系统思维被打破，而不是仅仅被暂停。

例如，假设你正在构建一个依赖于算法的功能，并且所涉及的依赖关系使整个问题变得棘手。对于这样的问题，需要更高层次的系统思维。问题太复杂，太相互依存了。

考虑到这种风险，你可能会将自己与 Slack 消息和会议隔离开来，但标准的开发实践仍然可以通过分散你的注意力来打破你的心流状态。例如，当你完成一段代码后，你可能会在写提交消息时从心流状态中滑落。

但因为没有人真正打断你的工作，你可能不会意识到那种机械、平庸工作的成本。你甚至可能因为没有完成工作而责备自己：你为了一个没有干扰的一天而奋斗，得到了，但你没有任何可以展示的东西。这感觉很糟糕。

减少碎片化思维的三个方法

将问题重新定义为碎片化思维的好处之一是，有很多减少碎片化的机会；坏处是，有很多选择可以做出。一些需要团队范围内的投资，但你可以在倡导更大的流程变化的同时进行个人层面的工作。

1. 创建正念和推动实践。 2018 年的一项研究侧重于良好的工作习惯，2023 年的一项后续研究侧重于推动，发现反思性目标设定可以提高生产力(80% 的人同意每天反思会有所帮助)，而定期推动可以帮助开发者更好地结构化他们的工作日和工作习惯。这听起来很简单，但事实证明它是有效的：通过更加意识到生产力和专注力的威胁(尤其是自我干扰，鉴于我们之前发现的)，你可以做出明显的改进。

2. 减少技术债务，减少浪费时间。 在 2018 年的一项研究中，研究人员发现由于技术债务，开发人员浪费了 23% 的工作时间。大部分浪费的时间来自执行额外的测试、源代码分析和重构。当然，“只是消除你的技术债务！” 可能是不可行的建议，但它表明了一个看似个人的问题——保持专注——往往是组织问题的结果。

3. 使信息可访问，以便你可以继续开发。 2023 年，StackOverflow 像每年一样调查了广泛的开发人员，其中一些结果与这里相关。根据研究：

54% 的开发人员发现“等待问题的答案经常会导致中断和干扰我的工作流程。”
64% 的开发人员每周会遇到五次知识孤岛。
63% 的开发人员报告说，每天至少需要花费 30 分钟来搜索答案和解决方案。

更好的文档和协作工作流程可以做很多事情来减少上下文切换并增加专注力。工具也可以有所帮助 - 例如，考虑采用开发人员门户和人工智能支持的文档搜索工具。

投资于你的惰性

根据我的经验，开发人员已经厌恶无用的会议，他们有权保护自己。如果你还可以了解自我干扰的成本并努力保护自己免受碎片化思维的侵害，那么你就可以更长时间地保持心流状态。

然而，这项工作需要团队和组织范围内的投资。问问自己和你的组织以下问题：

构建内部工具和设计系统的团队如何帮助简化或消除低水平的工作？
你可以做出哪些工具选择来减少低水平的思考并优化高水平的思考？
你从其他开发人员那里可以学到什么，以便你可以继续改进你的工作和开发环境？

你可以而且应该懒惰，因为狂躁、分心、碎片化的工作不会导致生产力和价值。但是，以这种方式赢得懒惰的权利需要团队范围内的工作和组织范围内的投资。这是一个挑战，但每个人都会受益于满足它 - 包括那个同事，他将不再因为提醒你一封关于某事的电子邮件而被你训斥。

本文译自 stackblitz，由 BALI 编辑发布。

赞一个 (12)

PREV : 今日好价 0429
NEXT : 洛杉矶用AI预测无家可归人群