Become a Productive, Distraction-Free Developer

Most work environments are filled with distractions. Whether you’re in an office or even working remotely from home (arguably worse), distractions are everywhere, and they’re non-stop. Even something seemingly simple like a text message can really throw you out of focus. For a developer, that focus is critical when you’re writing code – which is where you spend the majority of your time.

Aside from text messages and such (more on those distractions later), there’s a specific little-known form of distraction we like to call out, known as ‘context switching’.

Context switching explained

In the simplest terms, ‘context switching’ is one way to describe moving from one task to another.

Minimizing your current browser window to check a new email, being poked on the shoulder by a teammate with a question, or leaving GitHub to update a ticket in JIRA, are all great examples of that distracting context switch.

When you jump from one task to another, there’s a cost. That cost is due to context switching. It’s mentally draining, and it wastes way more time than you’d expect.

The true cost of context switching

It turns out that people are actually pretty bad at multitasking. A study by the Journal of Experimental Psychology demonstrated that multitasking slows productivity by up to 40%. When interrupted, it takes about 20-30 minutes to get back on task (for example, jumping from GitHub into another tool to update a task board). Exact numbers vary, but the takeaway is the same: shipping software quickly requires complete focus.

Even what you think are short interruptions slow you down.

Switching between low-performance tasks – say, texting a friend and watching TV – isn’t so difficult. It takes nearly no time to get back to “where you were” (zoning out in front of Netflix) prior to the interruption. When tasks are complicated, context switching becomes much more expensive.

Consider a developer who’s working on a new feature – an incredibly complex task with high mental overhead. Here, a five-minute interruption takes many multiples more than just five minutes. Steve Fenton, author and Development Director at Geronimo Web, describes it this way:

If a developer is interrupted with a question, it could put their work back by hours for each interruption. This is because of the amount of stuff they are holding in their immediate memory while they are working on a feature. They will have parsed lots of code in the area they will be working on and will have projected their changes in their mind before they start coding and the interruption will impact their focus on this information.

Additionally, once interrupted the developer may decide to batch other interruptions like email into the break – but this elongates the gap and makes it more likely that the information will be squirrelled away into harder to access places.

Eliminate the context switching

Agile teams have known this for a while – it’s the same reason many teams impose work-in-progress (WIP) limits when allocating tasks. They know giving developers two tasks to do “at once” takes more time in aggregate than doing one thing at a time.

It’s not enough to tell our teammates not to get distracted. Even your tool set should reflect your commitment to keeping developers focused. That’s why we built ZenHub inside GitHub – not close to, not integrated with, but inside. When your project management process is right there next to the code, using it becomes almost automatic. The cost of context switching – the time it takes to jump from GitHub, refocus, jump back to GitHub, and refocus yet again – is essentially eliminated.

(Unconvinced? This well-known multitasking simulation does a good job of spelling out just how terrible we are at switching tasks.)

It isn’t only engineers that lose focus when they context switch. Staying on a single task is equally important for managers. Centralizing in one place means:

• More accurate metrics. Third-party project tools result in silos of information. By making GitHub a single source of truth, your data is always up-to-date.
• More focus on the product. Project managers shouldn’t spend their day reminding their team to update tickets. When everything is centralized, project managers spend more time worrying about the product, and less time worrying about the people building it.
• Fertile ground for collaboration. GitHub issues were built for collaboration. Collaboration not only helps reduce error and technical debt, it actually keeps teams happier. In one study, enterprise companies that identified collaboration as the top priority significantly improved employee satisfaction, customer retention, and productivity (Aberdeen Group, 2013).

Minimize other distractions too

We’ve touched on text messages as an example of unwanted distractions, but they aren’t alone. There are a few simple steps you can take to eliminate, or at least minimize, these distractions.

Nearly all mobile phones and computers today have handy little notification settings that let you to customize the way you receive them. In a society where it may sound impossible to turn off notifications completely, you will be pleasantly surprised to experience just how much less distracted and more focused you become. If you still want notifications to come through while you’re not at work, you can often create a specific schedule (say 9am to 5pm only) when you want notifications disabled.

Email is another great example of a common distraction that can be avoided. Many of us have the habit of checking our email several times per day, or even have it open as a browser tab 100% of the time! Similar to your notification schedule, build yourself an email-specific schedule. Add events to your calendar at the beginning and end of every day to create that dedicated time for checking email. When not popping over to an email tab 10 times throughout the day, a developer will write an awful lot more code.

These simple tips, in combination with no longer having to context switch (because you’re staying in GitHub), will make you the most productive developer on your team. But obviously we think your entire team should use ZenHub too, so you shouldn’t rely on this alone if you’re looking to outpace your teammates during your next sprint.

Do you have questions about ZenHub? We’d be more than happy to help on Twitter @ZenHubHQ or email us directly.