Interruptions are a software developers worst nightmare. This is what you often hear. There is nothing worse than being interrupted while working hard on a problem, while you’re in the zone. You’ll lose your train of thought and the world collapses.

The idea is that in software development you are sometimes very deep into a problem, analysing code:

This orchestrator calls that service, it is managed by this class and talks to that queue. So this generator has these parameters and it all depends on… “hey I still need your time sheet”

Poof… everything gone. Your mind is now filled with rage and lost the entire train of thought. This is the main reason programmers hate interruptions.

Root cause analysis

During the JavaOne 2016 conference I attended a talk by Holly Cummins called “Euphoria Despite the Despair”. In this talk she went in depth into what makes work fun and stressed the point that interruptions should be avoided at all cost.

She even talked about a team that has a dedicated duo that had ‘interruption duty’. A Slack-bot was created so you could ask which colleagues you could interrupt each day.

But… are we judging too quickly here? Are all interruptions bad? I don’t think they are. Time to dig a little bit deeper.

Sync versus async and good versus bad

Interruptions are synchronous and blocking. Someone walks up to you and stands near your desk trying to get your attention. You might have a few milliseconds to finish what you are doing but you’ll need to reply. Other forms of communication are asynchronous, for example mail or chat clients (Slack). Someone asks a question and when you have the time to reply, you reply.

Our team has evolved to use this to our advantage. Some problems ask for direct action, but most can be handled asynchronous. This is something we talk about and discuss.

For example: If my manager wants a time sheet? Ask me asynchronous, it can wait. If a colleague has a question but is able to do other things first? Ask asynchronous, it can wait. If a colleague is stuck and can’t continue to work? I’d be happy to drop what I’m doing and assist! This is what teams do, they work together and communicate!

Don’t throw all interruptions on one big pile and label them as bad, distinguish between the good and bad interruptions.

Mount the headphones, get in the zone

Sometimes, as a programmer, you just want to concentrate and solve some deep problem alone.

In our team this can be done in two ways:

1. Work at home or in a small dedicated room in our office
2. Put on your headphones, if they are on, you signal you don’t want to be disturbed

I do this too, mostly using my headphones. Most of the time I don’t even have music playing and I can hear everything the team says (this is important, more on this below!).

In my opinion though we need to rethink this. Is it really the best way to program when you are ‘in the zone’?

I think you are much more likely to solve problems when you openly share and collaborate. Pairing isn’t just for trivial work, instead: the trivial things are things you should do alone! Teams should have no secrets, at each point in time you should have a pretty good idea what each of your team buddies is working on. Actively ask questions, even trivial things.

Near-subliminal team updates

What? “Near-subliminal” team updates? Yes, I’m so sorry, I can’t think of a better name. Can you? Please tell me.

One thing that is very important in software development is the use of what I’ve just called near-subliminal team updates/mumblings. It is the main reason I have headphones on without any music, and why I don’t like working at different locations (at home or in cubicles).

Example

You are working on something and you feel the need to refactor a class. At this moment you say/mumble out loud:

“Hey team, I’m going to refactor classname because reason okay?”

This is what I call a near-subliminal team update, and they are very important. They can solve a lot of problems!

1. Maybe you don’t agree with reason, this is the perfect time to talk about that. You don’t want to wait until a code review and tell them it was a bad idea later the same day.

2. Maybe you are also working on something in classname and it might collide with your work. You don’t want to wait until you git pull and need to merge, tackle it right away!

3. Maybe it isn’t relevant to you at all (which is most of the time)… Well, most likely you don’t even really notice the update. It didn’t contain any trigger words. Terms you are working on or have an opinion about. You aren’t really interrupted and can continue to work.

Conclusion

To summerize:

1. Don’t treat all interruptions as evil, they are not…
2. If you are annoyed about interrupts, talk about it
3. Speak up, mumble, use those near-submliminal team updates!

Did I miss anything? How do you cope or deal with interruptions?

And please: If there is someone with a better name for these short near-subliminal status updates, let me know!