作者：Chris Parnin

我是在呆滞状态下撰写此文——低睡眠质量，忙碌，茫然无措以及频频被打断。我试过所有的补救方法：使用番茄工作法（游戏邦注：The Pomodoro Technique，这是一个用来在工作期间保持专注的简单可行方法）， 在咖啡店办公，戴上耳机，以及在夜深人静无人打扰的时候才工作。但工作被打断的情况却仍然无孔不入。

和你一样，我也是个“频频被打扰的程序员”。不幸的是，我们对于工作被打断的理解，以及重新保持专注的方法却基本上无济于事，这有什么依据吗？我们该怎么做？

被打扰的成本

每隔几个月我都会看到有人要求另一名程序员不要在上班时间戴耳机，或者频频被会议打断导致他无法做任何事情，而他对于公司的这些要求却是无可奈何。我很担心随着我们年纪的增长，我们对于处理这些心理负荷的能力也会逐渐下滑。

研究办公环境被打断成本的调查人员曾指出，被打断的任务完成时间一般比未被打断者多2倍，出错率也比后者多2倍。他们还发现，员工应该在分离的状态下办工，因为57%的任务都会被打断。

而对于程序员来说，我们却很难提供关于工作被打断的影响及普遍率的证据。一般来说，我们被打断之后再重新回到原来状态的时间至少是15分钟。接受访问的程序员的这一情况也基本相同。Y Combinator创始人Paul Graham强调了开发者与经理人之间日程安表的差别，37Signals创始人Jason Fried曾表示办公室就是我们被打扰的地方。

关于程序员被干扰的研究

我们使用Eclipse和Visual Studio针对86名程序员的1万次编程记录分析，以及414名程序员的调查结果显示：

*平均每名程序员被打断工作之后，要经过10-15分名才能再次进入编程状态。

*如果是在编写某个方法的过程中被打断，程序员在一分钟内恢复工作的比例仅为10％。

*程序员一天内大概只有一次在2小时内不被打断的状态。

我们还观察了程序员应对被打断状态的方法：

*多数时候程序员会到不同地方转转，以便重新找到编程状态。

*程序员会故意插入一些编译错误以迫使系统出现“障碍”提示。

*实在不行就运用源diff文件迫使自己重返工作状态，因为这是一个很棘手的任务。

最不应该干扰程序员的时间

调查显示，最不应该打断他人的时间就是他们正值高记忆负荷的时候。使用与神经相关的记忆负载（例如，通过衡量瞳孔直径）进行研究，可以看到出现于高峰负荷的打扰会产生最大的破坏（见下图）。

（图1：根据不同任务困难追踪个体的瞳孔直径随时间发展的变化。）

在我们的研究中，我们观察了编程任务中程序员的默读表达方式，以便找到他们在工作中的记忆负荷情况（见图2）。当人们在处理复杂任务时，就有可能出现默读的（电信号传递到舌头嘴唇或声带）情况。这种现象很早就引起了研究者的兴趣，有些人将默读信号视为我们思维的导管。最近，研究人员甚至还将这些信号破译成文字。

(图2：修改一款《俄罗斯方块》游戏时的13分钟编程任务所释放出的肌电图（EMG）信号。)

如果允许被干扰的人延缓其工作状态或者达到一个“良好的中断点”，那么这种干扰的影响有可能降低。但程序员通常至少需要7分钟才能从高记忆状态转向低记忆状态。有实验结果显示，程序员最不喜欢在以下几种状态被打断：

*进行多窗口编码的时候

*查找相关代码文档的时候

*理清代码逻辑构造的时候

*无法集中精力的时候

创造支持记忆力的环境

我们无法消除干扰现象（在某些情况下，干扰甚至可能存在好处，40％被打断的任务没有重新开工，也许是因为我们意识到这些任务没有那么重要，或者因为这些干扰让我们得以停下来重新考虑问题）。但我们可以找到减少那些因干扰而导致记忆失效的影响。在此我将介绍一些在编程时会受到破坏或者严重负荷的记忆类型，并探讨一些概念性补救方法。

前瞻记忆

前瞻记忆会提醒人们执行特定情况下的未来动作——例如，提醒你下班回家的路上买牛奶。

多项调查已经描述了开发者如何应对前瞻记忆失效的情况。例如，开发者经常在自己正在编写的代码中留下TODO（备忘录）评论。这种机制的一个缺点在于，开发者可能毫无阅读这些提示信息的动力。而如果推行一种预期性的提示，开发者可能就会有意留下一些编译错误以确保自己记得执行任务。但是，引进编译错误又会产生不同的问题，因为它们可能会限制你在同一个代码切换到另一个任务。最后，开发者还是会像普遍办公室白领一样，留下便笺和发送电子邮件提醒自己。

“智能提示”就是可以根据特定条件激活的提示，例如同伴检查代码，提示信息的空间接近性（见图3）。这基本上是便利贴的一种编程版本。

（图3：靠近提示源的提示信息会更容易进入眼球，而在其他项目或命名空间就不会太显眼）。

注意记忆

注意记忆掌管的是自由的潜意识记忆。开发者在代码库中进行相似的调整时可能会下意识地想起来——例如，开发者需要重构代码以便将组件转移到其他位置，或者更新代码以使用新版API，那么开发者就需要系统化并且谨慎地编译这些因调整而受到影响的位置。不幸的是，即使是一个简单的调整也可能产生许多复杂情况，要求开发者在代码中追踪许多位置的状态。更糟糕的是，在被打断之后，注意记忆中的追踪发送状态会迅速消失，而无数已访问和编辑位置又会混淆起来。

触点（见图4）允许程序员通过代码中的多个位置跟踪状态。研究重构实践中发现一些工具支持上的不足，其中之一就是缺乏追踪代码中多个位置的能力。开发者采取的一个变通方案就是，在重构时抛弃重构工具，依靠自己引入的编译错误进行提示。不幸的是，使用编译错误来跟踪调查并非通用解决方法，并且仍会产生错误。触点概念则起源于开发者如何使用编译错误。它们可以通过得到最近访问、编译和检索的所有代码点而自动恢复。

（图4：从搜索和编辑操作中创造的一系列触点，可让开发者看到哪个地方已经发生变化，并在需要特别注意的位置进行标记。）

联想记忆

联想记忆掌管一系列介于同时发生的刺激因素临床表现之间的潜意识联系。

开发者在处理不熟悉的代码时，通常都会遇到茫然无措的情况。这种迷失方向感起源于开发者必须回忆起自己正在查看，或者将要查看的代码位置时的联想记忆失败。研究人员认为在界面组件中缺乏丰富而稳定的环境提示（例如文件标签）正是阻止开发者恢复联想记忆的因素。

多种形态的刺激物会增加人们塑造联想记忆的能力。在这里，“形态”指的是一种由大脑特定区域（例如听觉或视觉路径处理）的独特知觉。关于不同形态以及相应刺激物的例子包括：视觉型（错误标记条，高亮代码），词汇型（文件名称）、空间型（滚动条或标签的位置）、操作型（文件上的编辑/搜索/调试步骤）以及结构型（层次中的文件逻辑位置）。

当多种形态出现在同个刺激物时，就可以激活更多路径，因此可以增加开发者形成联想记忆的机率。反之，仅有一种形态的单调刺激物形成联想记忆的概率也会更低。

联想链接可以通过使用一个程序元素定位多种形态信息来帮助程序员。针对开发者的观察结果表明，他们经常依赖带有环境提示的联想，例如标签和滚动条，以便在导航的时候不迷失方向。然而，这些提示通常都不够充分：

导航动作经常会打乱提示状态，而标签等界面元素的不足（通常只包含一个文件名称）也影响联想记忆。通过优化导航文件标签（其默认配置尤其是spartan通常只显示文件名称），我们可以增加联想记忆。

（这两个标签使用了不同形态的提示：例如错误线（视觉型）和编辑图标（操作型））

情景记忆

情景记忆是对过去事件的回忆。软件开发者总会碰到与自己的技能有关的新知识。保留和使用这些已经掌握的知识，要求开发者回想起这些来自他们情景记忆的经历。

回想情景记忆的时候，开发者通常会遇到阻止自己回想起一些重要细节或关键事件的失败情况。例如，开发者可能会忘记他们为某个编程任务进行的调整，或者忘了一些细节（比如用于执行部分任务的博文）。

代码故事是一种能够帮助开发者回想起情景细节以及编程活动历史的情景记忆。不同类型的故事都可能发挥作用，例如，针对高级事件的观看模式，以及发布其他代码任务的共享模式。

（编程活动的时间线可以让你或团队成员记住你当时怎么执行任务，以及你所使用的资源。）

概念记忆

概念记忆是一种介于知觉与抽象的连续体。大脑如何记住铁锤等物品以及“工具”等概念？首先，它要掌握所遇刺激物的基本特性，比如铁锤的木纹和金属弯状，然后将这些特性逐步组织成更高的抽象度。

开发者在自己的职业生涯中要一直保持技术专长。不幸的是，成为专家的路并不好走：有证据表明，对新手而言，他们可能要历经10年才可能成为专家。而对于想进军新领域的专家来说（游戏邦注：比如桌面开发者想面为网页开发者），那就需要将原来的许多概念放置一边，并学习新知识。

关于专家与新手区别的研究发现，这两者的不同表现起源于不同的大脑活动。专家所需的脑力活动比新手更少，他们还使用了大脑的不同部分：专家使用的是概念记忆，而新手则使用注意记忆。也就是说，能手能够利用大脑中的概念记，而新手却主要运用注意记忆。

这里推荐使用Sketchlet（alpha版），它是一个支持抽象化、回顾需要更新概念，帮助程序员形成概念记忆的软件工具。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Programmer, Interrupted

by Chris Parnin

A reprint from the April 2013 issue of Gamaustra’s sister publication Game Developer magazine, this article, aimed at programmers, explores ways to help you take your work back from distraction.

I’m writing this article in a dull state: low sleep, busy, disorientated, and interrupted. I try all the remedies: using the Pomodoro Technique, working in coffee shops, wearing headphones, and
avoiding work until being distraction-free in the late night. But it is only so long before interruption finds a way to pierce my protective bubble.

Like you, I am “programmer, interrupted.” Unfortunately, our understanding of interruption and remedies for restoring focus are not too far from homeopathic cures and bloodletting leeches. But what is the evidence, and what can we do about it?

The cost of interruption

Every few months I see another programmer asked to not use headphones during work hours or interrupted by meetings too frequently to do any work, who has little defense against these demands. I also fear our declining ability to handle these mental workloads and interruptions as we age.

Researchers who have studied the costs of interruptions in office environments estimate that interrupted tasks take twice as long and contain twice as many errors as uninterrupted tasks. They also found that workers have to work in a fragmented state, because 57 percent of tasks are interrupted (see References for citations).

For programmers, there is less evidence of the effects and prevalence of interruptions; typically, the number that gets tossed around for getting back into the “zone” is at least 15 minutes after an interruption. Interviews with programmers produce a similar number. Nevertheless, numerous figures in software development have weighed in: Y Combinator founder Paul Graham stresses the differences between a maker’s schedule and a manager’s schedule, and 37signals founder Jason Fried says the office is where we go to get interrupted.

Studying programmer interruption

Based on an analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio, and a survey of 414 programmers, we found:

•A programmer takes 10-15 minutes to start editing code after resuming work from an interruption.

•When interrupted during an edit of a method, a programmer resumed work in less than a minute only 10 percent of the time.

•A programmer is likely to get just one uninterrupted two-hour session in a day.

We also looked at some of the ways programmers coped with interruption:

•Most sessions programmers navigated to several locations to rebuild context before resuming an edit.

•Programmers insert intentional compile errors to force a “roadblock” reminder.

•A source diff is seen as a last-resort way to recover state, since it can be cumbersome to review.

The worst time to interrupt a programmer

Research shows that the worst time to interrupt anyone is when they have the highest memory load. Using neural correlates for memory load (by measuring pupil diameter, for example), studies have shown that interruptions during peak loads cause the biggest disruption (see Figure 1).

Figure 1: Tracking the change in pupil diameter over time for individuals given tasks of varying difficulty.

In our study, we looked at subvocal utterances during a programming task to find different levels of memory load during programming tasks (see Figure 2). When people perform complex tasks, subvocal utterances (electrical signals set to the tongue, lips, or vocal cords) can be detected. This phenomenon has long intrigued researchers, some likening subvocal signals to the conduits of our thoughts. Recently, researchers have even been able to decode these signals into words.

If an interrupted person is allowed to suspend their working state or reach a “good breakpoint,” then the impact of the interruption can be reduced. However, programmers often need at least seven minutes before they transition from a high memory state to a low memory state. An experiment evaluating which state a programmer less desired an interruption in found these states to be especially problematic:

•During an edit, especially with concurrent edits in multiple locations

•Navigation and search activities

•Comprehending data flow and control flow in code

•IDE window is out of focus

Structuring your environment to support your memory

Ultimately, we cannot eliminate interruptions. (In some cases, interruption may even be beneficial; 40 percent of interrupted tasks are not resumed, and possibly because we realize that the task is not as important, or because the interruption gives us a chance to reflect on the problem.) But we can find ways to reduce the impact on the memory failures that often result from interruption. In this next section, I’ll introduce some types of memory that get disrupted or heavily burdened during programming, and discuss some conceptual aids that can support them.

Prospective memory

Prospective memory holds reminders to perform future actions in specific circumstances — for example, reminding you to buy milk on the way home from work.

Various studies have described how developers have tried to cope with prospective memory failures. For example, developers often leave TODO comments in the code they are working on. A drawback of this mechanism is that there is no impetus for viewing these reminders. Instead, to force a prospective prompt, developers may intentionally leave a compile error to ensure they remember to perform a task. However, introducing compile errors creates a different problem, because they inhibit the ability to switch to another task on the same codebase. Finally, developers also do what other office workers do: leave sticky notes and emails to themselves.

A “smart reminder” is a reminder that can be triggered based on specific conditions, such as a teammate checking in code, or spatial proximity to a reminder (see Figure 3). It’s basically the
programming equivalent of a Post-It note.

Figure 3: An ambient reminder that becomes more visible as you get near the source of the reminder (e.g., not visible when in another project or namespace). Click for larger version.

Attentive memory

Attentive memory holds conscious memories that can be freely attended to. This can come up in programming when a developer has to make similar changes across a codebase — for example, if a developer needs to refactor code in order to move a component from one location to another, or update the code to use a new version of an API, then that developer needs to systematically and carefully edit all those locations affected by the desired change. Unfortunately, even a simple change can lead to many complications, requiring the developer to track the status of many locations in the code. Even worse, after the interruption, the tracked statuses in attentive memory quickly evaporate and the numerous visited and edited locations confound retrieval.

Touch points (see Figure 4) allow a programmer to track status across many locations in code. Studies examining refactoring practices have found several deficiencies in tool support, and one of those is the lack of ability to track many locations in code. As a workaround, developers abandon refactoring tools and instead rely on compile errors that were introduced when refactoring.

Unfortunately, using compile errors to track changes is not a general solution and can still lead to errors. Touch points are inspired from how developers use compile errors. They can be recovered automatically by deriving all points of code recently visited, edited, and searched for.

Figure 4: A set of touch points created from a search and edit operation, allowing a developer to see which places have changed and flag locations that may need special attention.

Associative memory

Associative memory holds a set of nonconscious links between manifestations of co-occurring stimuli.

Developers commonly experience disorientation when navigating to unfamiliar code. The disorientation stems from associative memory failures that arise when a developer must recall information about the places of code they are viewing or what to view next. Researchers believe the lack of rich and stable environmental cues in interface elements, such as document tabs, prevent devs from recalling associative memories.

The presence of multiple modalities in a stimulus increases the ability to form an associative memory. In this sense, a modality refers to a distinct type of perception that is processed by
distinct regions of the brain, such as auditory or visual pathways. Examples of different modalities and corresponding stimuli include: visual (error underline bars, highlighting code), lexical
(name of file), spatial (position of scroll bar or tab), operational (edit/search/debug step action on file), and structural (logical position of file in hierarchy).

When multiple modalities are present in the same stimulus, more pathways are activated, thus increasing the chance of forming an associative memory. In contrast, a monotonous stimulus with a single modality is less likely to form an associative memory.

An associative link helps a programmer by situating information of multiple modalities with a program element; observations of developers suggest that they frequently rely on associations with environmental cues, such as tabs and scrollbars, for maintaining context during navigation. However, these cues are often insufficient: The act of navigation often disturbs the state of the cues, and the paucity of interface elements such as tabs, which often contain only a file name, starves associability. By improving navigating document tabs, which in default configurations are
especially spartan, often showing just the name of the document, we could see increased recall from associative memory.

Two tabs adorned with cues of different modalities: such as error lines (visual) and edit icons (operational).

Episodic memory

Episodic memory is the recollection of past events. Software developers continually encounter new learning experiences about their craft. Retaining and making use of such acquired knowledge requires that developers are able to recollect those experiences from their episodic memory.

When recalling from episodic memory, developers commonly experience failures that limit their ability to recall essential details or recollect the key events. For example, a developer may forget the changes they performed for a programming task, or forget details such as a blog post that was used for implementing part of the task.

A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity. Different types of narratives can be supported; for example, a review mode for high-level recall of events and a share mode for publishing a coding task for others.

A timeline of programming activities can help you or your teammates remember how you did a task and the resources you used. Click for larger version.

For more on code narratives, check out this blog, which is shared and published semiautomatically via a code narrative. (Note that as of this writing, the blog hasn’t been updated recently.)

Conceptual memory

Conceptual memory is a continuum between perceptions and abstractions. How does the brain remember objects such as a hammer and concepts such as “tool”? Well, it first learns basic features of encountered stimuli, such as the wood grains and metal curves of a hammer, and then organizes those features into progressively higher levels of abstraction.

Developers are expected to maintain expertise in their craft throughout their careers. Unfortunately, the path to becoming an expert is not easily walked: For a novice, evidence suggests this can be a 10-year journey. Furthermore, for experts trying to become experts in new domains, like the desktop developer becoming a web developer, there are many concepts that must be put aside and new ones learned.

Studies examining the difference between an expert and novice find that performance differences arise from differences in brain activity. Not only do experts require less brain activity than novices, they also use different parts of their brains: Experts use conceptual memory whereas novices use attentive memory. That is, experts are able to exploit abstractions in conceptual memory, whereas novices must hold primitive representations in attentive memory.

Sketchlet (alpha) is a software tool designed to help a programmer form and prime concepts by supporting abstraction and reviewing concepts that need to be refreshed. You can try it for yourself at sketchlet.sourceforge.net.（source：gamasutra）