Being interrupted when you’re in the middle of a piece of work can sometimes be annoying, sometimes disastrous. Here, Mal Pinder, one of our Developers, explains why it’s good to welcome interruptions and shares some ideas for managing them.
It is a common trope that interrupting developers is a disastrous thing. For instance, you may have seen this comic entitled “This is why you shouldn’t interrupt a programmer” or read this blog post on the subject by Erik Dietrich.
Of course, these sentiments are often intended as a joke or as hyperbole, rather than as a serious commentary about the realities of programming. But often it is serious, and even humorous things can become internalised, both by people who are doing programming and people who interact with programmers.
Interruption as collaboration
The problems with this trope are twofold.
Firstly, it elevates programming work above other kinds of work, casting it as more difficult or more valuable, and that’s just not true. We rely on all the members of our various teams in order to build FutureLearn. Encouraging some teams to work in isolation, while robbing others of the support they need to do their jobs, isn’t going to go well.
The second problem is to cast programming itself as an independent, hyper-complex activity, best done alone with headphones blaring. This is also not true – just look at how popular pair programming is. Developers need the help of other developers all the time. Whether it’s because they aren’t sure how to solve a problem, or just want another opinion on some code, working together is best for everyone.
We want to encourage a collaborative working environment, and we want to work effectively as a team, so we need to make sure people can get what they need from each other, when they need it. That means interruptions and disruption are going to happen – but at the same time, too many interruptions can make people feel unfocused and frustrated.
Personally, I like being interrupted by people – I see assisting and informing others as an integral part of my job, and I get a lot of satisfaction from knowing that someone values my input. However, I can also appreciate that some people don’t see it that way, and I can also understand that sometimes people have days when they just need to get something done.
To make sure we’re all working well and feeling good about it, how can we manage interruptions so that they don’t cause us trouble? Here are three ideas:
1. Make problems smaller
Firstly, we need to reduce the productivity loss from interruptions. That means reducing the overhead we have when context switching – the time it takes to refocus on what you were working on after you’ve put it down.
Sometimes, problems are complicated to work on, and you can’t avoid that. More often, the problems are simple, but there’s lots of them. That can look like working on several things simultaneously (“I’ll take a look at this other ticket while the test suite runs”) or working on one overly large problem without breaking it down.
One solution is to do fewer things at once – write down the things you need to do, and do them one by one. Another is to make sure that the problems you’re working on can be broken into small parts, by making systems simple through frequent refactoring. If it takes you 15 minutes to remember what the code you’re looking at does, it does too much.
2. Decide when interruptions are OK
Another thing we can do is to make sure that we all feel positive about interrupting others. Some of that feeling is down to the person being interrupted, but a lot of it that feeling comes from the process of deciding who to talk to, and when. We can make that process feel good by removing things we might be uncertain or worried about.
For instance, at FutureLearn we use Slack a lot. For some of us, it’s a low-priority “reply to this when you’re not busy” channel, but for others it’s a very immediate medium. How we signal our availability can differ too – for instance, are headphones a “do not disturb” sign or just a way to listen to music?
The best way to resolve this is by talking to each other, clearly stating our preferences, and approaching consensus on what different communication channels mean, so that we all feel empowered to go talk to each other.
3. Give people space when they need it
Lastly, but just as importantly, is the flip side of the coin: making sure that people can get the space they need, when they need it. That “space” might range from working from home or away from your desk, to smaller things like signing out of Slack, to saying “sorry, not right now” when someone does interrupt you.
A culture that supports people’s boundaries is one that encourages them to communicate honestly with each other.
We all feel different things at different times, and it can be tricky to make this communication effective and not feel like we’re repeating ourselves. So, some of us have customised our desk labels to do it for us – mine and Melinda’s (pictured above and below) show our two different feelings.
No one wants to feel that it’s wrong to talk to each other, and no one wants to feel that they can’t get anything done. We don’t get it right all the time, and there’s always more to do, but in order to keep building a great platform we have to be committed to working as the best team we can be.
Got a tip for managing interruptions? Leave it in the comments below. Want to know more about how we work? Check out more “Making FutureLearn” posts.