Programmer Interrupted: The Real Cost of Interruption and Context Switching

Interruptions and context switching are the two most costly factors that directly impact a programmer's daily productivity. Although there is no permanent way to avoid them, there are some interesting strategies to minimize their impact.

The Cost of an Interruption

Based on various scientific studies, it takes at least 10-15 minutes to get back into the "zone" after an interruption (Parnin:10, vanSolingen:98). Depending on the complexity of the task and your mental energy, it can definitely take more than just 15 minutes:

If an interruption occurs when you have a lot of balls in the air - multiple pieces of unfinished code fitting together in a complex way - then returning to the flow state can be more challenging. This concept is well-known to every programmer, but probably only a few have heard about The Parable of the Two Watchmakers, which perfectly captures all those details in a comprehensible form, even for non-programmers:

There once were two watchmakers, named Hora and Tempus, who made very fine watches. The phones in their workshops rang frequently and new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer. In the end, Tempus lost his shop. What was the reason behind this?

The watches consisted of about 1000 parts each. The watches that Tempus made were designed such that, when he had to put down a partly assembled watch, it immediately fell into pieces and had to be reassembled from the basic elements. Hora had designed his watches so that he could put together sub-assemblies of about ten components each, and each sub-assembly could be put down without falling apart. Ten of these sub-assemblies could be put together to make a larger sub-assembly, and ten of the larger sub-assemblies constituted the whole watch.

The Cost of Context Switching

When switching between complex programming tasks, it is typically more mentally challenging to return to the flow state than it is from a "simple" interruption. Fully switching to something else requires flushing the cache (short-term memory) and loading an entirely new context. This process takes time, effort, and mental energy, which is finite and depletes throughout the day. These hard limitations are imposed by the human brain.

There is an exceptional book written by David Rock, called Your Brain at Work, that I highly recommend if you are interested in improving how you spend your mental energy throughout the day. The gist is to treat your brain, during a deep work session, as a stage. As a session starts, you slowly introduce essential actors (objects, tasks, and pieces of information) into a scene (short-term memory aka cache). To properly light up a scene, you need to use some energy - mental energy.

Mind as a stage, during a long deep work session

When you get distracted, the entire stage collapses, and it takes effort to rebuild it from the ground up. However, there are some handy techniques to rebuild it faster.

Rebuilding The Context

For programmers, rebuilding the context after a task switch usually involves going back to old code that was previously edited or debugged. Before editing starts, programmers navigate to several locations to rebuild the context (Parnin:10). However, task resumption can become much more painful if an IDE doesn't remember the previous working state. This usually means:

last opened files,

cursor position (line & column) for every opened file,

breakpoints, watch variables and expressions,

bookmarks,

windows positions with the same layout (including tab's splits).

Rebuilding the last working state in an IDE manually is usually a real pain and mentally challenging:

Losing this functionality interrupts my workflow beyond imagination. The opened documents represent a "bookmark" for me and I'm barely able to pick up work again without them.

Every time this happens (...) I am willing to put hours into finding a solution, because the thought of losing my opened document state once more after a work session is terrifying . But this time around (...) nothing of the usual remedies helps (...) This has added another 20 minutes and counting to my two hours put into solving this.

and programmers are perfectly aware of the problem:

This is a much bigger problem than it sounds as you then need to use other ways to remember what you were working on. This causes A LOT of lost time - source.

It’s so frustrating to have to keep pinning the same tabs over & over & over & over & over & over (I think you get the point). (...) My productivity goes down , and my stress level goes up! - source.

Which is why, the ability to save working state is now considered a fundamental feature of every good IDE nowadays. However, this was not always the case. Vim introduced :mksession command in the v5.2 around 1998:

A Session keeps the Views for all windows, plus the global settings. You can save a Session...