The Real Cost of Interrupting an Engineer

Ingeniarius Intermissis

On many occasions I have found myself having to explain to those outside of the engineering world why unplanned interruptions are so, well, disruptive. I describe the mode of being in the zone, so completely deep in the understanding and comprehension of a task that a phone call, a question or just the need to say 'hello' to us is like pulling out the wrong block during an intense game of Jenga - everything falls down.

To be crystal clear - it is an extremely fragile period of enlightenment. 

​Arg.

​Arg.

Much to my delight a new study has been released that categorically supports the notion I've been describing for so many years, albeit more eloquently and accompanied with much more scientific rigor.

Chris Parnin over at ninlabs research released a study based on

the analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers...

Some top level data points that I can relate to:

A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
A programmer is likely to get just one uninterrupted 2-hour session in a day.

Brutal.

When is the worst time to interrupt an engineer?

Research shows that the worst time to interrupt anyone is when they have the highest memory load. Using neural correlates for memory load, such as pupillometry, studies have shown that interruptions during peak loads cause the biggest disruption

I called it 'being in the zone' - Chris calls it 'highest memory load'.

Fascinating stuff.  It's a great read and I highly recommend it to those who find engineers to be the grumpy sort.  It may just change your opinion.