“Pair Programming” is two developers focussing on one task and taking turns to “drive” the development. Normally this means sitting down together and passing a keyboard back and forth in ten or fifteen minute intervals, but can also mean screen-sharing remotely.
We believe that pair programming produces better work for a number of reasons: because two minds are better than one, because the additional attention on your work increases your focus and because you learn new things as you go.
However, there are times to pair and there are times to go alone.
Best: When you’re starting something new together
This is the absolute best possible time to pair. When you’re starting a new project, whether you’re a team of two or more, sitting down together and spiking the project as a team is extremely beneficial. It means you all start work with a common understanding of how the entire project works. It provides a good opportunity for team members who aren’t familiar with new technology or code to learn in the shallow pool, rather than being dumped in the deep end months later. It means everybody is able to get involved in style and philosophical discussions before the code thats laid down inevitably becomes the project standard.
This has the same relative benefit when working on a smaller scale, whether it’s starting a sprint or epic, or even implementing a new feature in an existing project. Spreading knowledge and discussing the problem will help you a lot in the long run. Pairing in these situations almost always means starting something off in the best way you can.
Best: When you don’t fully understand the work or understand the business motivation
Although developers should be involved in iteration planning, sometimes you won’t be aware of what an individual task entails. Given it’s reasonably complex, you may feel you’ll take a long time trying to understand and complete it yourself. In these cases pairing with somebody more knowledgeable of the given task can help get it off the ground and ease your discomfort quickly.
In fact, pairing is extremely good for knowledge sharing in all cases, even when you’re working on something you’re already knowledgable about or comfortable with. A senior developer pairing to upskill a junior, for example, will often learn just as much throughout the session. They’ll commonly pick up language features or idioms which they haven’t seen before, and even teach themselves things as they are forced to focus on the code they’ve written in much more depth. Explaining your decisions to somebody is a great way to notice flaws, potential edge cases or unnecessary complexity.
Worst: When there’s too much work to divide your time
The truth about pairing is that, in the worst case, you more than halve your time when you do it, and even in the best cases you’re not getting 100% of it. Any reasonably skilled developer can figure out and complete a task by themselves. Putting two developers on a task will generally reduce the time it takes to complete the task, while providing the other benefits that come along with pairing, but they will rarely complete it in half the time it would take a single developer. You have to be aware that no matter what a positive impact pairing may have on the project, in many cases your time would have been better spent doing separate tasks. When there’s a lot of work to do and not a lot of time, don’t spend your time pairing unless you need to.
Worst: When you know exactly how you’d do something
Sometimes as developers we envision exactly, in great detail, how we’d develop a feature. We’re excited to build it and we know the steps we’d take and the techniques we’d employ. In these cases I’ve found that it’s better to go alone, although it’s certainly worth talking through your implementation details with somebody else beforehand as a sanity check and for inspiration. When you pair on features like this, it’s difficult to resist the urge to grab the keyboard and type it yourself, or to “backseat program” and narrate what you’d type to them. Pairing is about sharing the development and the responsibility, not about following the leader. A pair partner should never behave like this so if you think you will, and you won’t be teaching them anything in the process, either stop and try to get over it, or just take the ticket yourself and see it through alone.
Worst: When you’re tired of pairing
Pairing is a great way to get you out of your rhythm and it forces you to think differently. It encourages innovation, a high quality of code and learning new things. But it gets tiring. Talking all day is tiring. Breaks are encouraged every hour or so, but not on your personal schedule, and the intense degree of focus you have to keep up all day can burn you out by the end of it. It’s fun and extremely valuable, but leaving a pairing session and getting back to working on your own can be just as refreshing as pairing is in the first place. Plus, I’ve noticed that relying on somebody else for too long can make developers lazy. I try and pair about 40% of my time, an amount I’d recommend. I’ve gone on longer stretches and enjoyed them, but “too much of a good thing” can apply here.
Use your best judgement: When you’re doing something you always do
There are some things you know better than anyone else you work with. The things you work on a lot become muscle memory to you, and you can achieve all those common tasks quickly. They become so much slower when you’re pairing. If you know exactly how to accomplish something because you do it a lot, your ten minutes on the clock will either be spent racing through, with your pairing partner struggling to follow along, or crawling along while you explain every action you’re making. Their ten minutes will be spent making incremental changes as they learn, while you sit impatiently.
You’re not enjoying this, but only because the reason you’re pairing matters a lot in these situations.
When the work is easy for you, pairing to get things done is rarely a good idea. Instead, in these circumstances, you should be pairing to upskill your colleague, or to share understanding of some part of the codebase you’re responsible for alone. Storing the shared understanding of a problem or business area in a single person means things can fall apart when they’re away. We don’t accept single points of failure in our infrastructure, nor should we in our team. Pairing in these situations can an extremely beneficial way to teach team members new things.
Ultimately, pairing is nearly always valuable. There’s rarely a situation where the work suffers from being developed by multiple people, as you’re getting constant peer review throughout development. Although it can sometimes take longer, when it does it’s generally because you or your pair are learning something new and being upskilled in the process. This will give you the ability to pick up similar tasks in future and complete those quicker.
I learn something new in every pairing session and would greatly encourage it. Just make sure you go in with the right task and the right attitude.