Developers struggle with context switches

If you want to know what people are struggling with, look for the memes.

Jokes are rooted in consensus (or at least in a shared perception) so if you find a meme going around, chances are it’s describing a pain point that a group of people share.

It’s no surprise then, that there are so many memes and comics out there showing developers suffering from interruptions and context switches.

Every single developer will tell you that getting interrupted in the middle of a task is an absolute productivity killer. And it’s not just a theoretical problem. Our recent Livecycle Collaboration Study found that nearly 50% of developers are actively struggling with this problem in their current workflows.

Having studied dev-team collaboration for the better part of the past year as head of Product Marketing at Livecycle, it’s amazing to me that in this regard, the system is basically set up to fail.

Take the following sequence of events for example, which illustrates a common workflow dilemma that many developers face:

1. Developer works on Task 1
2. Developer completes the Task 1 and merges it so that other stakeholders can review
3. Developer moves on to Task 2
4. Review comments for Task 1 interrupt the developer’s current focus on Task 2
5. Developer context switches from Task 2 back to Task 1, which affects the quality and schedule of both tasks It’s the ultimate can’t live with ‘em, can’t live without ‘em scenario.

On the one hand, developers must have the flexibility to focus on their current task. On the other hand, the completion of any given task requires subsequent reviews by other stakeholders. These reviews often translate into comments, questions, and ultimately unexpected interruptions for the developer who has since moved on to another task or project.

And this is just one of the many workflow scenarios that play out every day and similarly impact developer productivity and output.

At this point, the developers reading this are probably nodding their heads in empathetic agreement. And the non-developers out there might be thinking - so what? Isn’t this the developers’ problem? What does this have to do with me?

It’s important to recognize that the developers’ problem is - by extension and by definition - a problem for the product and the entire company.

In fact, according to data from a recent McKinsey study, removing points of friction from the development workflow to enable a higher “developer velocity” directly and positively impacts the bottom-line success of businesses across all vertical markets.

So this is not just a problem for developers. This is a fundamentally important issue for all dev teams and businesses to confront head-on.

Why context-switching is so painful for developers

In order to have any chance of addressing this problem, we need to better understand what is causing it in the first place.

And to better understand the root of the issue, let’s borrow the “maker vs. manager” framework made popular by Paul Graham in a blog post from 2009.

Paul writes as follows:

“One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming in the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.”

According to Graham, the makers and the managers operate on two completely different wavelengths. And trying to mix the two is a recipe for instant tension and friction.

We can use these same categories to understand the inherent issue with context switching.

When another stakeholder approaches an active developer with a question, or a review comment on a previously submitted task, the two colleagues might be involved in a single conversation, but they are certainly not speaking the same language.

The person interrupting the developer is operating in “manager” mode. There’s a specific task or question that needs to be dealt with in a vacuum. It’s just another item in a lost checklist of tasks to complete before the end of the sprint.

For the developer, however, this context switch represents a fundamental shift from maker mode to manager mode. And it is this jump (and its lingering effects) that causes all of the personal, professional, and technical tension that we end up laughing about in those industry-joke memes.

Two approaches to handling the context-switching crisis

This maker vs. manager framework can also help us understand the many solutions that have been suggested to address this tension. Because in analyzing proposed solutions over the last several months, it seems pretty clear to me that you can divide all the suggestions into two general approaches.

The ‘manager mode’ approach

The first approach is what I’ll call the “manager mode approach”. This approach addresses developer context switching by basically accepting the problem for what it is and running damage control.

This approach accepts that developers will have to toggle between maker-mode and manager-mode throughout the workflow and it will probably come at a cost. But we can limit the effects of this sub-optimal reality with some surface-level productivity hacks and scheduling practices.

I recently saw a list of concrete suggestions in a thread on Reddit asking about ”Developer context switching - tips & tricks”. All of the suggestions in the comments fit neatly into the “manager” approach:

Aggressively book blocks of focused work time in your calendar

• Turn invisible in slack, close down email, etc
• Turn off audio notifications in Slack
• Use the “StayFocused” chrome extension to block every social-media/etc website
• Use Brain.fm for very good focus music.
• Create “no meeting” days
• Read productivity books like Getting Things Done

While all of the above are fine suggestions, they do a disservice to developers and dev teams in that they assume that we need to live (and work) in a constant state of tension and they imply that developers will need to shift into manager mode at some point. In the context of development workflows, these suggestions are more band-aids than they are real solutions to the actual problem.

The ‘maker mode’ approach

This brings us to the second approach to dealing with context switching mid-development: The “maker-mode” approach.

The maker approach takes a step back to reassess the situation in a more holistic way. It assumes as a default premise that a developer should be empowered to maintain focus in “maker mode” as much as possible. This is the status quo that should be maintained. If any part of the workflow is to be modified in a creative way, it should be the way that we gather and process feedback from the other stakeholders. Perhaps there are less intrusive ways that we can include these other stakeholders in the review process that do not directly affect the developer’s default need to stay focused on their current task.

It might sound too good to be true. But this is exactly the approach that we’ve taken in building Livecycle.

How Livecycle enables the ‘manager’ approach

When we analyzed these issues, we recognized that the “Pull Request” was a tool that we could better leverage as the key to a more optimal workflow. For all intents and purposes, each Pull-Request is opened by a developer as the ‘Ready for review’ moment. Developers are actually asking for feedback from their peer developers before they merge the code changes back to the ‘main’ branch.

We saw an opportunity to piggyback on this moment in time to include all relevant stakeholders by automatically creating a sharable and isolated environment that allows practically anyone on the team to experience the latest changes on their own.

Building and hosting a representative version of the code change and sharing it with more stakeholders is the first critical step to a more inclusive Pull-Request workflow that simultaneously includes others while freeing developers to work on other tasks.

And then we take it one step further.

Not only do we provide a preview environment ‘playground’ for other stakeholders per PR, we also include an annotation layer on top of the playground itself, so that all relevant collaborators can leave clear comments in their original context, on top of the product UI. And not only do we keep all of this feedback organized in Livecycle we also sync it back to Git so that the code owner can review and address it when they are ready to do so.

By working from the baseline assumption that we should keep developers in “maker mode” for as long as possible, we’ve been able to take a more creative and more fundamentally correct approach to tackling the context-switch issue.

So, using Livecycle, the problematic workflow we outlined above would now look something like this:

1. Developer works on Task 1
2. Developer completes the Task 1 and merges it so that other stakeholders can review
3. Developer moves on to Task 2
4. Review comments for Task 1 are collected instantly and asynchronously and they DO NOT interrupt the developer’s current focus on Task 2
5. Developer can complete Task 2 (or break at a logical stopping point) and shift focus to address all Task 1 issues at a time that makes sense

Our more inclusive and collaborative approach to PRs offers teams a number of immediate benefits:

• Reduce context-switches → Once you merge your feature branch you can actually move forward to your next task once and for all.
• Instant review gathering → Control and Invite the feedback whenever you need it (just as you do with peer developers when asking for code review)
• Reduce ambiguity of branches and maintain a clear Git structure
• Automatically create an audit trail for all needed feature changes by all stakeholders in the company
• Always on reproduction environment for every commits → Making your SCM an application time machine.

Perhaps the biggest benefit to this “maker” approach is that is simply preserves (and amplifies) the natural state of each of the participants. Coders can focus on coding. Other stakeholders (who are perhaps more oriented towards the “manager” way of doing things) can focus on completing their reviews better and faster. And everyone involved does their work asynchronous, eliminating those unnecessary interruptions and context switches.

Enjoy those memes while you still can…