People in the project

In every project, there’s someone who tests, supervises, checks the progress against the goals and business objectives. There’s someone responsible for the contact with the customer, requirements, quality assurance. Rarely it’s something a software engineer must worry about. These people make plans, meets with customer representatives, test application, and so on. Their job is split into time-framed tasks.

In the same project, there are software developers. Developers solve problems that require a deep understanding of the whole system and a situation. They need to remember many things at once. Consider the context of the operation they currently work on. Everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. They work in task-framed chunks of time.

Impact of interruption

Whether the manager, tester or the developer: none, of course, likes to be disturbed in the middle of a thinking process. And the last thing a dev wants to do is to jump into a business meeting out of the blue.

However, something that is a small interruption to an average person can be a disaster for a developer.

The developer, when working with code, will methodically go through the code to understand, refactor and change the functionality or fix the bug. And when he/she is adding new features it’s even more absorbing (depending on the complexity of the feature).

Now imagine what happens when you approach the developer in a middle of that task? Now, if you think he/she can pick up where he/she stopped you couldn’t possibly be more wrong.

We can’t! Not without a hit on every level – time, quality, and the ability to think deeply.

When I concentrate on writing a code it doesn’t take much to put off stride.And the worst are those days when there’s a lot of demands on my time so that I forget what I was doing in the first place. The days when one minute the architect is asking me about the application’s impact on the client’s system and the next a person from customer’s contact is telling me that I must explain to him how the new report is working in case the customer will have questions. Not to forget about overflowing e-mail and instant messages. After few hours of such distractions, the simple code written in the morning might as well be in Japanese.

And I know there’s more developers like that.

Developer’s need of “undisturbed” time

Planning and building a complex IT systems is a difficult and unpredictable process, and there will be challenges that come up along the way. People, who don’t write a code, do more time-framed tasks or have more procedural jobs underestimate context switching cost that developers are facing.

Please remember: every developer needs quiet time during a day to get his/her job done. Even though developers are fully aware they can’t completely avoid interruptions, there are times when one single moment can cost hours of work. It will influence developers’ productivity and thus a project outcome (it’s nice shown on this picture).

A team’s culture constantly evolves through a number of small actions and decisions that gradually turn into regular patterns and ways of working. When you understand what the developer’s day-to-day life is like and where they are coming from it’ll be much easier to understand each other and to work through challenges that are yet to come.


  1. At boot camp we had a system
    headphones (even unplugged) == DO NOT DISTURB
    And since everyone understood why it had to be that way, everyone respected the headphones symbol. I imagine dealing with people who don’t get it provides a great opportunity to either practice self discipline/anger management OR releasing all that pent-up rage on someone who truly deserves it. Jk

    Liked by 1 person

    1. Yeah true. In my situation it’s slightly more complicated: I work remotely. Unfortunately, IM status set to “busy” sometimes isn’t enough so when days are pretty hectic I either split them into two parts and am available to the team for 5 hours during “regular working hours” and then do the rest of the job in the evening/night or (when I’m extremely desperate and the release is just around the corner) I change my status to “do not disturb” and leave the status on IM that I’m available on the phone (in urgent cases) – so I still can be reached when needed.

      Liked by 1 person

      1. On the project I am working on, we have two geographically seperated teams (Cork, Ireland and Kassel, Germany). It is very common to get interrupted. Very often by questions where you can simply google the answer or by investing ~3 minutes of thinking for a solution.
        I use a very effective and easy strategy to minimize the impact of distraction: Wait 15 – 20 minutes before answering a IM/Slack message. Most of the times, the problem is resolved by then by the person who is responsible for this anyways. Those interruptions are often caused by impatience of some folks. So give them time to think on their own, before sacrificing your own time. Don’t forget: Those people are also paid foe thinking. If a problem lasts more than 20 minutes, then it might be worth your attention.
        I know it is somehow nasty, but project managers can get even more nasty, if you keep missing deadlines. Especially if you tell them, that’s everyone else’s fault.

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s