What is it and why do it?

Pair programming requires two programmers (if more, it’s called a mob) to use a single computer. One developer will work, while discussing what they are doing with the other. The second developer might also have a computer or other device and use it to take notes, look up things for the first developer, review specifications, etc.

Basically, the idea is that with two developers working on a piece of code, you avoid creating knowledge silos, improve the quality of the code you are writing, and increase team cohesion by having people actually work together. Team cohesion from pair programming is often an undervalued result, but is especially important when dealing with remote and distributed teams.

Even in organizations where pair programming is not common, it does often happen during onboarding a new team member. The larger practice of pair programming can be viewed as a long term extension of this onboarding practice.

When to pair program?

You are probably not going to want to pair program all the time, since it can be exhausting. Instead you should be more strategic about when you do it. Ideally, you will only pair program when it actually provides value. Pair programming works well when you are trying to show another developer something they haven’t seen before.

It also works well when you need two people’s expertise to actually complete a task. This happens a lot when porting an old system to a new framework, or when trying to migrate data between systems. It’s also good for onboarding new developers and getting them used to your company’s processes. Pair programming is very effective when you need another developer’s help to get unstuck.

When not to pair program

It’s very difficult to pair program when the two developers involved don’t get along, have a major language barrier, or don’t use similar technologies to do their job (unless one of them is trying to learn the technology used by the other). When you don’t have a clean way to share a screen and to give control to the other party (some security setups make this difficult, especially when you are remote).

When either party is overloaded with a completely different task, where the pair programming would be a burden. When people have a lot of pressure on them, pair programming is unlikely to be a positive experience due to the stress level. When your session is likely to be interrupted at random intervals. You need a long period of focused time in order to pair program.

Who should be in control?

While generally pair programming should be a cooperative effort, someone has to run the computer. This tends to be a position with a lot of control, although you need to make sure the other party gets input. It can be difficult to decide who is the best person to control the pair programming session. Sometimes, one person wants to do it and the other doesn’t, so it’s easy.

If both people want to control the pair programming session, then you should choose the person based upon the goal of the session. Is the goal to get something done? To teach one person something? If so, your goal should drive the selection of the person who “drives” the computer. If neither person wants to do it, you should spend some time examining why. It may not be a good time to do it, or you may not have adequately defined the purpose of the exercise. Or it may be that you both just need a break and some coffee.

When to switch places?

If the pair programming session is very long, one person shouldn’t be in control the entire time. Rather, control should change hands, either when someone gets tired, starts getting stuck, or when the task is better suited to the other person. The person driving will eventually get tired and it will happen faster than you think. Once they start making mistakes, slowing down, or getting frustrated, it’s probably time to switch places.

Switching places doesn’t mean that you stop doing anything. Rather it means that you should be doing things like looking up supporting documentation, using chat tools to talk to stakeholders, taking notes, etc. You also should be helping the person who is actively doing the work, and paying attention to what they are doing.

The idea here is that one person is working, while another is sanity-checking what they are doing, while keeping track of any ancillary tasks. This helps the work keep moving, keeps both people informed on what is going on, and keeps productivity high enough that the pencil pushers in accounting don’t notice it as much (if that’s a problem).

Taking breaks

If doing a longer pair programming session, you should take frequent breaks. It’s better to schedule these before the session if possible – this avoids the awkwardness of people having to ask for bathroom breaks and the like. It’s also probably smart to take breaks if both parties get to the point of being too tired to focus. You aren’t going to do good work in this state and it increases the risk of problems later.

Both people in the pair programming session probably also have other responsibilities, so it’s important to balance those with the requirements of the session. Whatever you do, don’t let other stuff fall apart while you pair program, or it will be hard to justify doing it again. Don’t be overly focused on productivity. While it is important, if you aren’t used to pair programming, it’s more important to avoid burning out, or creating interpersonal problems. Tempers will flare if people are stressed, so be aware of this.

How to know when you are done.

The most important thing to learn when doing anything (besides knowing when to start) is knowing when to stop. While pair programming is useful, it only works for short bursts. Past that point it gets tiring. When the breaks stop being effective (ie., you are as tired after the break as you were before it), it’s probably time to stop for the day. While many developers feel like they can code long bursts alone, you’ll find that many more introverted developers tire out far more quickly when pairing.

When a major problem comes up that you have to stop to address, you should probably stop for the day. You lose a lot of context when this happens and it’s rare in corporate environments for problems to appear entirely by themselves. If you are doing remote pair programming and communication issues start cropping up, it’s probably better to stop and come back when the internet is working properly. While you can push through this, it is really distracting and is likely to significantly blunt your effectiveness.

How to sell this to management

If you don’t have to ask, it’s generally better if you don’t. While you don’t want to do regular and long pairing sessions without management approval, the occasional request for “another pair of eyes” is something you can usually get without asking.

If you want to sell the idea long term, however, wait until you have a particularly thorny problem and then suggest pairing on it. It’s easier to justify in such circumstances, and if you can prove it works there, you are more likely to be able to get approval for it in less dire situations in the future. Make sure that if you talk to management about this that both parties are involved in the conversation and both have useful observations. If just one person talks, management is liable to believe that the other one just sat around watching.

How to sell this to project managers

Project managers will also tend to be reluctant to allow pair programming, especially when there is a certain amount of throughput expected in a typical sprint. They often see pair programming as a direct threat to throughput (which it can be, over the short term). As with regular managers (assuming they aren’t the same person), the workflow is probably best executed by working together and then making the project manager aware of what you learned and the upsides that you saw.

However, be aware that there can be a rather uncomfortable dynamic here, especially if the project manager reports to the same manager that you do and productivity happens to drop – they are liable to focus on the pair programming session even if something else was the problem. If you are like many teams, your productivity bottleneck may not be development. Pair programming may actually ease pressure on the bottleneck by lowering your current WIP count, which means the stuff downstream from you can perform more effectively. You may see that the WIP decrease is not reflected at all in a throughput decrease downstream, both because of the higher quality and because the pipe is saturated further down.