Pair programming is when two developers sit together at the same computer to write code. There’s lots of different techniques for pairing and takes more than just moving your chair over to your colleague’s desk. Discovering the most effective way to pair takes some effort, and looks different for each pair of developers.

Pairing can be very useful, but there are other times when it isn’t necessary, or when the term is misused. Here are some scenarios when I don’t consider pair programming to be the right choice.

Please bear in mind that this is all my personal experience and opinion and you will probably have very different ideas!

1) This work needs to be completed quickly, let’s pair

This notion generally comes from project managers. There’s a misconception that pairing will halve (or at least reduce) the amount of development time needed to complete a task - and why not, there’s two brains working on it now! This has never been the case for me.

Pairing takes time: both developers need to understand the task. They need time to discuss solutions, they need to agree on a solution and make sure they understand how they’re going to tackle the solution. Time is taken setting up the pairing workstation, and writing code as a pair is often slower, particularly if one partner tells the other what to write.

2) We don’t have enough work for the developers, let’s get them to pair

Again, something that comes from project managers. Not every task is suited to pairing, and so making developers pair on a task just because there isn’t enough work available for them to work individually isn’t a good enough reason to enforce pair programming.

If a developer has free time, why not find some technical debt in the codebase to improve, or allow them to research or learn a new skill (one that’s still relevant to their job mind you, I don’t mean French).

3) There’s a new-starter on the team, let’s pair

To me, this isn’t pairing. Sure, you’re sitting with another developer, but it’s more like shadowing (if the new-starter isn’t doing any active work on the computer) or teaching.

4) There’s a junior on the team, let’s pair

If you’re admitting that one partner is more junior, then this relationship is better described as teaching, rather than pairing, which implies that it’s more equal. However, even in teaching, the developer who knows less should be given plenty of oppotunity to actively participate and engage in the work, rather than just watch another developer.

5) Pairing is used when a tech huddle would suffice

Sometimes developers don’t know how to approach a feature. This doesn’t mean they need to pair. A tech huddle with a more experienced developer would suffice, where they could discuss how to tackle the problem. Sometimes all a developer needs is a push in the right direction and they can complete the work more effectively on their own.

Conclusion

I feel the term pairing is misused when a different phrase or technique could be applied to describe the situation better. It might feel like I’m being pedantic, but by using the right language, colleagues will have better expectations.

Pairing can be tricky to get right and I think there should be more discussions within a team on how to approach it to get the best results. This could involve using different phrases to describe working relationships, or just avoiding pairing when it’s not the best choice.