Pair programming is great - I enjoy it a lot, and I know how productive it has been in the agile teams I have worked with over the years. This post however is not about how cool it is - there are plenty of other pieces on that. The subject here is some tips on how to manage pair programming without having to deal with the carnage if it goes wrong :)

The basic issue is that for many personalities common in software engineering, pair programming is stressful, extremely stressful, if not managed correctly.

Us engineers have a reputation for being OCD, prickly, loners, introverts, etc. Frequently that is true, to some extent; software engineering is a self-selecting profession. We have usually been trained to work alone (even within a team). Being required to pair program can feel like a nightmare for many at the start. Someone always breathing down your neck, not giving you space to think, continually judging you, ready to gleefully pounce on each and every mistake you make.

Pair programming is not an easy switch to make. It’s one of the hardest things to get a team used to in the teams I have been part of or coached over the years. To do it successfully, each team member has to be willing to change their deeply ingrained mindset, to be inclusive rather than introverted, and also to be willing to go out of their way to remove causes of stress for themselves and their teammates.

A few pointers:

Hygiene - WASH YOUR ####### HANDS! ;) Seriously, this is probably one of the biggest causes of tension in a pairing team. Many of us are a bit obsessive about personal hygiene. Being forced to work in very close proximity to those who aren’t is disgusting and stressful. It’s hard to work well when you don’t actually want to touch that sticky keyboard or greasy mouse. Wash your hands, frequently, properly, with soap. Yes we all have immune systems; that doesn’t mean it’s ok to have poor hygiene.

Also, it’s very hard to focus on the task when you’re trying to not breathe the odours emanating from the person next to you. Learn to shower before work and after exercise or travelling and use deodorant.

It may seem shocking that people actually have to be told this, but think back on the team members you have had - apparently some did need to be told. It’s a lot better to just quietly have a word with the team member (or probably more correctly, get the team lead to do it, it’s their job), than everyone being irritated and just talking behind their back. The office Secret Santa gifts of soap and deodorant do happen; I’ve seen it in some teams.

If team members persist in inflicting their poor hygiene on the rest, it’s up to the team lead to remove them. It’s better for the team as a whole.

Other tips for making people more comfortable are for the team to have adequate supplies of hand cleaner and antiseptic wipes for cleaning the keyboards and mice - that is always appreciated. Worst case, you can set pairing machines up with multiple keyboards and mice. I tended to do that anyway as I use a trackball, which didn’t suit my pairs, so there was also a connected spare mouse. That avoids the whole issue of avoiding particular teammates’ desks because their keyboards were encrusted with layers of spilled breakfast (yup, that happened).

Listen to your partner - Many of us are predisposed to doing the geek rant - getting upset about something trivial, or being utterly intransigent about a design or coding decision. If we’re not careful, we’ll tend to take a position and argue it to the death, rather than admit we are wrong. This can manifest in pairs as long, involved discussions about why this particular line of code is a better way of doing it, all the way up to blazing arguments and team members refusing to work together. Most of the time the issue being discussed is pretty trivial.

A simple way of avoiding these situations is to just be prepared to hear your partner out. Try to see where they are coming from. If there is no clear objective winner of two approaches, just pick one. If necessary, code both of the choices up and see how they look. If it takes two minutes to code both solutions up, there’s no point in spending twenty minutes arguing about it. If you’re both entrenched in your positions, put a shout out to the team and go with majority rule. Do it quickly rather than bickering about it.

If it is a recurring point of contention, bring it to the attention of the group and get a vote on how to handle the general case. That way future instances aren’t going to waste time.

Limit pair durations - When pairing we quickly discover those we work well with and those we don’t. We have a natural tendency to just stick with our buddy. It is good to have someone we just mesh with, but it’s not a good approach for the team. It’s better overall to get used to working with a variety of personalities. It’s less comfortable individually, but it prevents longer term frictions from building up.

If you’re stuck pairing with the same person for a long time, it’s likely to go wrong. It’s much better and less stressful to mix up the pairs frequently. Pair with someone for a short task, then when the task is done after a couple of hours max, pick up the next task with someone different. Move around.

You’ll find with this flexibility that knowledge dissemination is much faster. If you pick up a task you’re not familiar with, pair with the person with more experience in it. That way the task gets done and you get to learn something. If your pair is someone you aren’t entirely comfortable with (it takes time to build up a rapport), then a short pair duration limits any friction that could build up.

Take breaks - Pairing is intense, even with someone you’re totally comfortable with. That level of focus is very tiring. If you need to take a five minute timeout every half hour, do so. But don’t have someone continue working on the task while the other is taking a break; both of you take a timeout.

Desk layout - Set up your machines so that you can both comfortably work. It’s really hard to work if you’re perched on the edge of your chair, stretching across to reach the keyboard, or craning your neck to see the screen past your colleague. Don’t be territorial about your space. If you’re driving, move things around so you can code comfortably. If you’re navigating, get out of the way, but still be in a position where you can comfortably see what is being coded. Move the office space around to suit if necessary. In teams I try to make sure my desk is set up comfortably for two, rather than just for me.

Pair programming is hard. It is very intense, and the learning curve is painful for many. I’ve had many colleagues over the years who just can’t do it - they’re not psychologically equipped to be working that closely with someone. It happens, and there’s not a lot you can do about it. If you’re in an XP team, pairing is required, so those team members have to be transferred out to another team; there’s no option there. It’s better to move into an environment that is less personally stressful than persist in a team you dread working with every day. However for those who learn to like it, it is amazingly productive, both for personal improvement, and in achieving team goals.

Shared at https://www.linkedin.com/pulse/pair-programming-how-avoid-homicides-donal-stewart