Breaking the Flow: The True Cost of Interruptions in Software Engineering

Photo by Paul Skorupskas on Unsplash

In this post, I’ll explore the importance of deep work from a software engineer’s perspective and dive the various aspects of a typical work day, that keep us away from it.

While developer productivity (and productivity in-general) has been a hot topic in recent years, the rise of AI technologies and AI-assisted development has only intensified this focus. However, amidst to buzz of trending tools and jargons, one significant drain on productivity is often ignored – Context switching — and the cost of interruptions is often underestimated or not acknowledged.

Deep Work

This is the state of intense focus, peak productivity, creativity and fosters innovation; wherein engineers can perform cognitively demanding tasks in the most efficient manner.

Picture this — You’re working on implementing that new feature, you’re in your zone, it’s just you and the problem in front of you. You’re changing code, testing, debugging, thinking about the next piece of change, how that change will cascade through the various intricately connected cogs. You’re repeating the cycle — code, test, debug — code test debug — C T D — you’ve lost track of time, moving and morphing blocks of code from multiple files from multiple repositories are currently in your context, in your human RAM. You are in a trance, you are plugged into your computer.

With a sudden sound of *TUK.TUK.TUKK...* your colleague pings “Hey .. Can you help me with … ” on Slack (or MS Teams, if you’re unlucky).

And just like that, you’re snapped out of the zone. The thoughts of whatever they are asking about or seeking assistance with, starts filling up in your context (your human RAM). In the best case scenario, you’re able to resolve the conversation in a minute or two, with an exchange of few messages; And there’s still a slim chance of you being able to get back in the zone. But in the worst case scenario, they are asking for a quick ad hoc call to discuss something. This may be a 5 minute chat but it will definitely cost you a lot more time to get back to the same level of productivity after that call ends. The multiple moving blocks of code from various files and repositories have vaporized from your context by now. And you‘ll need to revisit things, re-trace your chain of thoughts and hope nothing else interrupts you.

The cost of interruption and the associated context switch

Now, it’s fair to acknowledge the importance of collaboration and communication within a team. But I want to focus on the cost of interruptions and explore ways to mitigate it while still having a high functioning team. Let’s walk through it by first -

Understanding Interruptions

Let’s first classify the nature of interruptions.

External Interruptions

These are disruptions that come from outside the person’s immediate work environment. Examples include:

• Production Incidents
• Internal Support (Colleagues asking questions or seeking assistance)
• Messages or Ad hoc calls
• Meetings

Internal Interruptions

These occur within the person’s mind and can be triggered by:

• Multitasking on different projects.
• Personal thoughts or distractions.
• The urge to check social media or slack/emails.

Environmental Interruptions

Factors in the physical workspace that can lead to interruptions include:

• Noisy surroundings.
• Poorly designed/cultured workspaces.
• Uncomfortable seating or lighting conditions.
• Or perhaps too many open tabs.

Effects of Interruptions

Interruptions can have several negative effects on a developer’s work, including:

• Decreased Productivity: Frequent interruptions lead to a loss of focus, making it difficult to complete tasks efficiently.
• Lower Quality of Work: When developers are interrupted, they may have no choice but rush through tasks, resulting in errors, bugs or subpar code quality.
• Impaired Creativity: Interruptions stifle creative thinking, making it challenging to come up with innovative solutions. Overall experience of work becomes less enjoyable.
• Increased Stress: Constant disruptions are mentally taxing; they can create a sense of urgency and pressure, leading to heightened levels of stress.

Mitigation

The expectation of absolutely no interruptions at work would be impractical. But now that we’ve understood the nature of interruptions and their effects, let’s explore ways to reduce interruptions and their impact on developer productivity.

Educate

Mitigation starts with educating the members of your organization about the causes and effects of interruptions. And I believe that this step alone might greatly improve the work environment and foster a culture of respecting each other’s time.

• Take a moment to think before interrupting some one. Sure, an engineer would be able to answer your question, but did you look at the API document, readme file, or a wiki page which might be able to resolve your question.
• If someone has set aside “focus time” on their calendar, honour it.
• Code reviews, design discussions etc. can be scheduled instead of an immediate interrupt on Slack followed by ad hoc call.
• Schedule regular check-ins, instead of ad-hoc interruptions to address questions and concerns, allowing engineers to plan their work around these times.

Meetings

The effect of a meeting goes well beyond the scheduled time frame of that particular meeting. For example, a meeting in the next 30 minutes, may prevent starting a larger task that would not reach a logical ending in those 30 minutes. Individuals may start preparing for that meeting — either exclusively or mentally/subconsciously while being unable to focus on task at hand. And after the meeting it would be similar to our hypothetical scenario mentioned earlier with residual thoughts from the meeting. Hence it’s imperative that team members and managers must be cognizant of the cost of meetings. Here are some measures that can be taken to mitigate this.

• Clear agenda: Set clear objectives of what the meeting will achieve.
• Recurring meetings: Review and adjust the frequency over time, as teams evolve.
• Time limit: Discussions often tend to expand to use up the entirety of scheduled time, while having to scramble through important points in the last few minutes. So setting up a shorter meeting induces efficient use of time.
• Too many chefs: Invite relevant stake holders only. Number of decision makers can exponentially reduce the decisiveness.
• If it can be an email: Informational meetings may be avoided altogether and sent over email or Wiki (Confluence) page

Production incidents

As an engineer on-call or otherwise, this interruption takes the top most priority and must be addressed as such. However this also makes it necessary to routinely audit the alerts in place, and tune them to reduce noise and increase actionability. Periodically review frequency, severity, impact and time spent on production incidents and the associated alerts. Prune non-actionable alerts, so that unwanted interruptions can be avoided.

Internal Support

Assisting and collaborating with peers is a vital part of high functioning teams by bridging knowledge gaps. However this can also become a source of significant interruptions for some peers, if the flow of internal support questions is not balanced. Availability of tools, documents, wikis etc. can help mitigate this issue, while also building a common corpus of knowledge for new joiners.

Personal organization

1. Set Boundaries: Engineers should communicate their availability to colleagues, establishing specific times for interruptions and focused work.
2. Create a Distraction-Free Environment: Minimize clutter, and design a workspace that promotes concentration.
3. Use Time Management Techniques: Implement methods like the Pomodoro Technique, where engineers work in focused sprints followed by short breaks to maintain productivity.
4. Limit Multitasking: Encourage Engineers to focus on one task at a time, reducing the cognitive load and minimizing the chances of internal interruptions.

Measure interruptions

If you can’t measure it, you can’t manage it

At an organization level, tools may be put in place to classify and measure interruptions, e.g. IM notifications, emails, meetings, etc. Comprehensive employee surveys to take stock of current situation and narrow down on parts of organization that may be suffering more than others.

Team Size

The number of interruptions can increase exponentially with the size of team, with an increased need of knowledge sharing and decision making. This doesn’t mean we shouldn’t have big teams, but rather a the big teams might benefit from availability of structured channels of communication to avoid haphazard interruptions, while a smaller team can get away with informal, ad hoc mode of operation as the number of interruptions are insignificant.

Conclusion

Interruptions are an inevitable part of a software engineer’s work life, but understanding their types and being cognizant of their effects can help in developing effective strategies to manage them. By fostering a work environment that minimizes disruptions, engineers can enhance their productivity, reduce stress, and improve the overall quality of their work and innovation. Implementing these strategies not only benefits individual developers but also contributes to the success of the entire development team.

References

• Here’s an interesting take on how interruptions are worse for programmers compared to non-geeks.
• Reducing Interruption to help engineers

A note on use of Generative AI:

It is important to mention that the entirety of this blog has been written in an old school manner – by hand; without using generative AI for writing any textual content.

Images/graphics were created using tools (like excalidraw) which may or may not be using AI under the hood.

A certain amount of online research goes into writing a blog like this, and again most of the search engines out there today use generative AI, e.g. AI Overview in Google OR Perplexity. But that’s purely research, and not the actual writing itself