The Cost of Distractions on Developers!

stay focusedEveryone who works in a multitasking environment or office has to deal with daily distractions, and developers are no exception. It’s well known that distractions are one of the biggest contributors to a developers reduced performance. Distractions not only delay task completion and increase the number of bugs, but can also lead to increased stress and frustration levels, which can then lead to even more delays… and in some cases, burnout. The average lost time is 23 minutes per major interruption, according to The Wall Street Journal (1). On top of that, programmers can take 10-15 minutes to restart editing code after resuming work from an interruption. According to Game Developer Magazine, an average programmer is likely to get just one uninterrupted two-hour session in a day (2).

Developers lose more time returning to a task than the average workers, and the longer they are away from the task, the more time is needed to get back to it. Programming is a mindset more than it is a writing skill. You have to fully wrap your mind around the task at hand, and plan and anticipate the outcome and desired results of each method and function all while coding and testing. Often times non-technical people can’t fully understand the thought process and focus required of a developer to do their tasks. So for those of you who are non-technical, try out this little test I found and see how you fair… Programmers, Teach Non-Geeks the True Cost of Interruptions.

Everyone jokes about developers being night owls, but there is some truth to this. Over the years of developing, I have learned to manage interruptions out of necessity. In my early years I spent many late nights coding, simply because it was the best uninterrupted time I could find. But looking back on it I realize, it was because I was not so good at managing distractions. So how do you manage distractions and better yet, recover faster from them while developing?

Simply put: planning, prioritizing and being honest to yourself and others. I know you thought it was going to be some magical tool that fixes it all, but that simply is not the case. Everyone who works in the IT industry knows how tasks and schedules can quickly get off track, or emergency situations arise, or the pipeline simply gets stacked to the point where you can’t see the light at the end of the tunnel. OK, enough drama… I follow these rules as much as possible to manage interruptions.

First, I make sure my major projects and tasks are already planned out. I get as much information as possible about them upfront so I  have few surprises. If I have to make assumptions, I let everyone know of my assumptions so there are no surprises. Having these tasks planned out, I can now calculate how much time I have left for other tasks that come up during the day. Don’t kid yourself — they will pop up.

When developing, I always quickly flowchart or document my processes to complete my task if there is no formal documents created. I then breakup my task into smaller tasks and assign an amount of time I will spend on each; I.E. DB & entity class development, security and access, automated tasks, testing and deploying, etc. Then I break down all my methods and functions I need, and write the shell of the application. I then review and make sure all my logic and method flow follow my plan. Finally, I code and unit test each individual method. I do this full process for three reasons.

  1. It makes larger tasks go much quicker.
  2. I can better judge how much time I have left at any point in the development process, and
  3. Most importantly, it’s much easier to pick up where I left off when I’m distracted.

Now, let’s talk about how you react to daily interruptions. The first thing to do when a distraction arises is a quick assessment of the urgency of the request and the time needed to address it. If you’re not sure about urgency, then ask! Based on the urgency and time needed and my current tasks status I have to make a quick decision to see if I can stop and if the new task severity warrants the interruption? If so, stop coding and document in your code where you left off and where you currently are in the process so it’s easier to pick back up. If the task urgency is low and/or it can wait then give the requester an estimated time for when you can address it. Explain that you want to give their task the full attention it deserves, but you’re currently involved in another task. If you get a lot of unscheduled requests per day, you may try setting aside time in your day to do those items and explain to others that you will get to their request at that time. Also, look for opportunities to save time by grouping like tasks together so you do not have to reset in between each task and when possible use a formalized ticketing system to gather and group all liked requests.

There are small things you can do to minimize your distractions as well. While in the office, wear head phones so others know you’re coding. You can change your email client to download email less frequently or set several breaks per day to check mail. Depending on your function this may not be possible.

Remember, that several small requests can actually hurt you more than one larger one. So don’t let your day get high jacked and be honest if you don’t have the time in the day to get to it. Better to be honest than to say you’ll get it done and you don’t, or worse, you jeopardize your current tasks. If a newer, larger, or more important request comes in with higher urgency and you have no choice but to change tasks, that is fine, but make it clear how this will impact your current task list.

Want some tools to help reduce digital distractions? Check out our insights on how to stay productive at work.

1.    Workplace Distractions: Here’s Why You Won’t Finish This Article. By Rachel Emma Silverman, Dec. 11, 2012.

2.    Programmer, Interrupted by Chris Parnin [Programming, Game Developer Magazine, Console/PC, GD Mag Exclusive], Apr. 22, 2013.


There are currently one response.

June 14, 2019

When I am doing my work programming, I use the methodology called Pomodoro. I don’t follow it’s rules 100%, because I’ve found that everyone has their own pace and style of working; my method is to base the length of my pomodoros on the length of time it will take me to complete a “feature”, or subsystem of that feature. Assuming most features take 4-8 hours, I will break that time into about 8 – 12 chunks, 30 – 40 minutes each, with some breathing room for standing and staying active.


Leave a Reply

Your email address will not be published. Required fields are marked *

two × 4 =

Request A Quote

Let's take your business to the next level. Fill out the form below to get started!

"*" indicates required fields

Sign me up for IronMail
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
This field is for validation purposes and should be left unchanged.