olly - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How developers focus despite open offices, concurrent projects

What do shared meeting calendars, pink sombreros and home offices have in common? They're all ways to combat distractions and let programmers focus on productive coding.

It's difficult to manage developer distractions. To improve developer focus, leaders must take specific steps to foster a culture that prioritizes work -- and lets programmers post a do-not-disturb sign when they need peace and quiet.

In 2008, a surprising fact about productivity made the rounds in the technology industry, and it changed the way we think about time management. Research performed by the Department of Informatics at the University of California, Irvine determined that it takes someone an average of 23 minutes and 15 seconds to recover from an interruption. That means that for every interesting tweet, quick question posed by a coworker, and overheard word of gossip, a developer loses nearly 30 minutes of productive time.

As many companies move to collaborative open-office layouts and hyper-connected chat platforms, it's more difficult to escape distractions now than ever. In an instantaneous world, people want immediate answers to every question, and every task is high priority -- all this leaves developers feeling overworked and undervalued.

Software organizations must curtail developers' interruptions to keep up with demand for new features and rapid bug fixes. If your development team needs a change, hereare six methods to focus on programming -- and tune out needless distractions.

1. Establish productivity-focused policies

A focus on focus can't just be an initiative within the dev team. Without the support of the entire organization, it's nearly impossible to prevent productivity-squashing distractions.

Developer productivity should be a tier-one metric for the business, so provide critical protections that enable them to do their work. Create policies that define developer focus time, emphasize meeting hygiene, and outline appropriate communication methods.

2. Prevent external interruptions

It seems obvious, but one of the best ways to improve developer focus is to prevent external interruptions. Think about that nearly 30-minute tax for every tap on the shoulder a developer receives from a coworker with a question or funny video or update on a business initiative.

Still, a healthy balance is required. Developers are still company employees, connected to business initiatives, and they can't be left to their own devices for eight hours per day, every day, for eternity.

Developers sometimes just need time to think about how they will build a product and solve problems.

To help developers designate productive time, provide a signal that anyone on the team can use to indicate that they don't want to be interrupted. In might be as simple as saying, "If someone has their headphones on, don't bother them." Some organizations issue Do Not Disturb placards that developers can put up. Get creative with these objects to encourage adoption: Put up pink sombreros or giant red "on-air" lights. If a coworker sees one of these objects on the desk of a programmer, do not disturb them. Each company can put their own spin on it, as long as it's understood that these items indicate a no-questions-asked way for developers to work without fear of interruptions.

3. Optimize and reduce meeting times

Meetings are a common source of developer frustration. Imagine that you are a developer with a fairly large workload for the day. For every 30-minute meeting you sit through, you'll need an additional 30 minutes to get back into a productive state. Add onto that time sink the tendency for organizations to stagger meetings throughout the day, and most of your day is lost before it really begins.

Some companies require employees to schedule meetings within small time windows or close together, to combat overload and downtime. Some companies have gone so far as to implement meetingless days, such as no-meeting Wednesdays. These measures segment time to reserve some days for uninterrupted productivity. Meetings can -- and should -- happen on another day.

4. Embrace remote work

Remote programmers can focus and be more productive due to the lack of in-person distractions. When organizations embrace working from home, they give employees the ability to organize their day in a way that makes them feel the most productive.

While meetingless days and interruption preventers are great policies, sometimes they're just not enough. Allow developers to work from an environment that maximizes their productivity, which also helps them compensate for unavoidable office distractions.

5. Enable, don't punish

Start from the objective of enabling productivity, not punishing the lack thereof. Micromanagement might seem like the best option when work isn't done as quickly as we expect, but it erodes employee trust. Developers might even see it as an affront to their competency as professionals.

Developer focus doesn't always look like typical worker productivity. Coding might seem like the only real form of useful development work, but the job also entails research and experimentation. Developers sometimes just need time to think about how they will build a product and solve problems -- there's no metric to track how they do that. Measure the project, and don't overanalyze what each person's process looks like.

6. When in doubt, personalize

There is no single answer for how to improve programmer focus. Nearly every company has its own set of policies, each carefully crafted to fit within their own culture. What works for one organization, or even one dev team, might not work for another.

When an organization embraces developer productivity as a priority, it can establish a foundation for its policies. From there, experiment with different ideas and get feedback from developers to improve their workday.

Dig Deeper on Software design and development

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Great piece and a topic I have been raising with clients since 1987.

That said, I'm curious as to where in the UC Irvine "interruption" study you reference, does the "23 minutes and 15 seconds" stat appear? I've read the paper a number of times and can find no such assertion.

Thanks.
Cancel

-ADS BY GOOGLE

SearchCloudComputing

SearchAppArchitecture

SearchITOperations

SearchAWS

Close