Cringe from crossing a concentrating coder

Some justifications why you should not disturb programmers while they are concentrating on work.

February 11, 2000

You should not break without good reason the concentration of a programmer while they are working. If at all possible, communicate via e-mail or some other way that lets them react when they have the time. What follows are some justifications as to why this is so important.

A programmer's work is divided roughly into three categories.

  1. Brainless gruntwork: moving desks and machines, printing and copying specifications, etc.

  2. Interrupt handling: answering the phone, dealing with most mails, sitting in meetings, some parts of testing and debugging, etc.

  3. Monomaniacal concentration: design, coding, some of the more demanding mails, testing, and debugging.

During points 1 and 2 interruptions don't necessarily hinder the work: if there are not very many mails and there some extra time, a phone call or coming in to the office to ask a question do not cause much disruption. During point 3 any interruptions at all will destroy everything.

Psychologists talk about a concept called "flow". A layman's explanation: when you are in the flow, you concentrate only on what you are doing and you hold all the required details in your head, in the short and middle term memory. Because there are no disturbances inside your own head, all the details are readily accessible to the brain and the brain in general works like a well-oiled machine, the work progresses excellently and working is a pleasure. If there are any interruptions in this state, anything that requires bringing other things into the short term memory, naturally anything you had there is lost and that breaks your concetration and the feeling of pleasure vanishes. Getting back into the flow usually takes at least fifteen minutes. During this period no useful work happens.

Tom DeMarco and Timothy Lister describe the flow in the classic project management book Peopleware like this (page 63):

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: "I began to work. I looked up, and three hours had passed." There is no consciousness of effort; the work just seems to, well, flow. You've been in this state often, so we don't have to describe it to you.

Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.

Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.

Once locked in, the state can be broken by an interruption that is focused on you (your phone, for instance) or by insistent noise ("Attention! Paging Paul Portulaca. Will Paul Portulaca please call extension..."). Each time you're interrupted, you require an additional immersion period to get back into flow. During this immersion, you're not really doing work.

One of the foundations of the Internet hacker culture, the Jargon File, defines the same concept as "hack mode" (http://catb.org/~esr/jargon/html/H/hack-mode.html):

hack mode /n./ 1. What one is in when hacking, of course. 2. More specifically, a Zen-like state of total focus on The Problem that may be achieved when one is hacking (this is why every good hacker is part mystic). Ability to enter such concentration at will correlates strongly with wizardliness; it is one of the most important skills learned during larval stage. Sometimes amplified as `deep hack mode'.

Being yanked out of hack mode (see priority interrupt) may be experienced as a physical shock, and the sensation of being in hack mode is more than a little habituating. The intensity of this experience is probably by itself sufficient explanation for the existence of hackers, and explains why many resist being promoted out of positions where they can code. See also cyberspace (sense 2).

Some aspects of hackish etiquette will appear quite odd to an observer unaware of the high value placed on hack mode. For example, if someone appears at your door, it is perfectly okay to hold up a hand (without turning one's eyes away from the screen) to avoid being interrupted. One may read, type, and interact with the computer for quite some time before further acknowledging the other's presence (of course, he or she is reciprocally free to leave without a word). The understanding is that you might be in hack mode with a lot of delicate state (sense 2) in your head, and you dare not swap that context out until you have reached a good point to pause. See also juggling eggs.

All programmers are in the flow at some point, preferably during most of their work day. If anyone enters the room to talk to someone, or calls, or otherwise interrupts, this will probably disturb everyone in the room. In the worst case, the flow of a great many people will be broken. Everyone will take fifteen minutes to get back into the flow, so one interruption of a few minutes can cause the loss of several hours of most productive work.

It is not necessarily clear to a casual observer, whether a programmer is in flow. Because of this, it is best to avoid any unnecessary interruptions and use e-mail.

If the matter is urgent, and there is no response to e-mail, it is of course all right to use text messages, to call, or to visit in person. Also, if the programmers are talking or it is otherwise clear they are not in flow, a visit is welcome.

(This essay was originally written for the internal mailing list for my employer of the time.)