Podcast: Play in new window | Download (55.1MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
You’ll often hear about developers (including both of us) who regularly use pair programming. The practice of pair programming can be very helpful for sharing knowledge across the team, working through a difficult chunk of code, or simply showing how your team approaches their daily workflow (especially when working with a new hire). Pair programming also helps team members get to know each other (and each other’s thought processes), which is very important in our current COVID age where people are working remotely.
It can be hard to convince management and other developers to allow pair programming. Your typical corporate bean counter will see the practice as simply doubling the cost of the same piece of work. Project managers will often view the practice as something that jeopardizes project timelines for dubious benefit. Other developers might balk at the idea as well, both because they are self-conscious about the way they write code and because many find it boring. Furthermore, to nearly everyone involved, it sounds like yet another meeting that will chew up part of a day (most meetings stink and most people don’t like them).
Pair programming is a useful way to improve code quality, cross train team members, and on-board new developers quickly without boring training. In addition to making it easier to solve more difficult problems, it also helps with team cohesion and helps people understand how other team members think. Best of all, if done properly, it may not negatively impact your team’s throughput – it could even improve it.
Basics Of Pair Programming
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.
While You Are pairing
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).
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.
Selling It To Non-Developers
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.
Tricks of the Trade
When working on a team or even just one other person such as pair programming, communication is key to everything being successful. This means that you need to have the ability to listen to the other person and set your own feelings aside to resolve any issues you may find. Your code may be working perfectly but not be functional because of how it interacts with theirs or how they need to consume it. That also means being open to dialog about the situation. Instead of saying, “This is what the code does.” with finality you could say, “This is what the code does now, what do you need from it?” to open up the discussion and determine what all needs to be adjusted. Sometimes it will be your code that needs to be adjusted, other times it will be their expectations that need to be adjusted.