Imagine that you’re playing an excessively large game of Memory. You’ve got a 15×15 grid of cards in front of you lying face down. As you turn cards over you need to remember what they were so you can match them up. You flip over 20 cards, and are learning enough information to be able to start making matches. Suddenly, you’re escorted away from the cards so that someone can quiz you on the history you’ve had with a particular client. Thirty minutes later you’re brought back to the cards to keep playing Memory.

At this point, you might remember a few of the cards from before, but it’s going to take you some time to get back up to the point where you’re productive. This is generally how it feels to write complex software. Sure, there are simpler tasks that aren’t like this, but as a general rule, assume this is what your developers are doing. They have a large amount of situational context in short term memory while they’re working.

Interruptions

Depending on the type of software you’ve created in the past, you may notice that your developers get particularly annoyed when they get interrupted. The reason they’re frustrated is because the interruption caused their mental context to collapse and they know they’re going to have to reconstruct it. It takes at least a half hour to rebuild that type of context. In interruption-heavy workplaces, this is exactly when another interruption comes along. It’s incredibly frustrating to spend all day setting yourself up for work without being able to actually do any, which is why developers react the way they do.

Of course, we understand that interruptions are part of the job and that they will happen. All that we ask is that you understand the cost when that happens.

If you want to read more about the correlation between ambient noise in your office and bugs in software, a fantastic book on this and many more topics is Peopleware: Productive Projects and Teams. The authors analyse data from more than 600 developers in 90 companies to make conclusions about how to work as effectively as you can with your developers.

The culture

Another thing to consider is that developers, by and large, function as a meritocracy. What you do (and how well you do it) determines your status as a developer. In a developer’s mind, if you create good code that’s easy to read, easy to maintain and works well, you should be promoted. If you don’t, you should be immediately fired. Developers often react very negatively when confronted with traditional HR methods for solving interpersonal problems, and don’t understand why others can’t see things their way. Remember, developers spend all day working in a world where whatever they create is either 100% right or it’s wrong, 1 or 0, yes or no. Your code works 100% of the time, or it simply doesn’t. People who are attracted to this field are often those who enjoy absolute clarity, but that luxury is often not afforded to anyone else in a professional environment.

Let’s get to work

So how do you get the best work possible out of your developers?

Firstly, allow the developers to determine how involved they want to be with everyone else. Sure, there has to be some limit to how removed from your corporate culture you allow people to get, but conversely, shoving some developers into a team building exercise that they don’t want to be a part of isn’t going to make them interact with others and suddenly fit into place socially. It’s just going to make them hate their jobs. Remember that for many developers, especially the more passionate ones, sitting alone in a room with no windows working on some new tech that nobody understands is an ideal weekend. So let them determine their involvement as much as possible. They’ll make their own friends in time.

Secondly, make sure that the people you choose to manage the developers can express their opinions logically. If they put something forward, they need to ensure that they’re ready to defend the idea on its merits, not because of who proposed the idea. Saying ‘Do this because I’m your boss’ will never get you good software. Explaining the reasons behind decisions is important for developers, mainly because it’ll give them more context into what you’re actually trying to do, which is always a good thing. Until they understand why you want something, they’ll often either misunderstand the requirements, or simply assume all sorts of things about the context and then give you software that doesn’t meet your needs. They’re asking why, not because they don’t respect you, but because they need to know.

Conclusion

If you look after your developers’ needs, they’ll reward you time and time again with innovative solutions created on time and on budget.