Because time is money

Fractured time: why are interruptions awful for developers?

Jane Elizabeth
© Shutterstock / Still Life Photography

No one likes being interrupted. By definition, it’s disruptive. But it turns out, the cost of interruption is higher than you might think.

Everyone’s got a work groove. A set up that improves and helps the flow of work, so the code and the words flow like spice. Being interrupted when you’re in the groove is like having a steel girder thrown in front of your train of thought: shock, frustration, and sometimes major property damage.

You’re not the only one. We reported last year about the true costs of interruptions. Workplace disruptions are commonplace among tech workers. Results from the High-Performance Employee Survey show that 80% of tech workers are interrupted at work at least 5 times a day.  Over 40% of tech workers are interrupted 8 times or more!

Tech is all about disruption, but this is a little much.

True cost of interruptions

What’s the cost of that little interruption? It’s a lot more than a momentary pause in the work. Throwing off someone’s groove might not seem like the worst thing ever, but it does have its consequences.

According to Professor Gloria Mark from the Department of Informatics at UC Irvine, her research shows that it takes an average of 23 minutes for an employee to recover on task after an interruption. Task switches are also classified as interruptions. That means if you bother your coworker Bill for a quick chat about her TPS reports, it’ll take her an entire episode of the Simpsons before she can really get back to work.

Over time, those 23 minutes add up. Let’s say the average full-stack developer is interrupted six times a day. That’s nearly 2.5 hours of lost work time. That definitely adds up over time.  Some back of the envelope calculations suggests that interruptions costs a worker 600 hours of work a year.

There’s even some research to suggest that the cost of interruptions is even higher for difficult tasks like coding. Iqbal and Bailey (2006) found that the cost of interruptions was lower for tasks designated as “lower workload” and the cost of interruptions was much serious for “higher workload” tasks. Unsurprisingly, the more you need to think about something, the harder it is to get back to thinking about it after an interruption.

In search of lost time

So, interruptions are bad. But not all disruptions are equal. Both planned interruptions and random interruptions have their downsides.

Random interruptions can be devastating for workflow. Iqbal and Bailey (2006) found that “Studies show that interrupting tasks at random moments can cause users to take up to 30% longer to resume the tasks, commit up to twice the errors, and experience up to twice the negative affect than when interrupted at boundaries.” Ouch.

Planned interruptions can be just as prohibitive. A set meeting in the afternoon acts as a sort of divider. Workers consciously change their workflow in order to accommodate meetings. We’ve all done it. It’s basically impossible to start working on a big project right before you’re schedule to leave for the day.

Either way, more interruptions cause workers more stress. Professor Gloria Mark published research in 2008 that showed over 30% increase in stress and almost 40% increase in frustration associated with task interruptions. Her conclusion? “People in the interrupted conditions experienced a higher workload, more stress, higher frustration, more time pressure, and effort.”

Can we fix it?

This isn’t an insurmountable problem, but fixing the problem of interruptions lies more in corporate management than in the individual developers. Managers need to schedule meetings better to allow developers longer periods of uninterrupted time. Longer periods of uninterrupted time mean better code. Better code means everyone’s happy.

Fixing the problem of interruptions is a difficult one. However, this is something that the tech industry could definitely do. Until then, maybe stop bothering Sam in Engineering about that one thing. “Can I just ask you a quick question?” might not be so quick after all.


The High-Performance Employee Survey is still ongoing and looking for participants.

Jane Elizabeth
Jane Elizabeth is an assistant editor for

Inline Feedbacks
View all comments