Pair Programming and When To Use It

What is pair programming?

Pair programming is when two developers work on the same task on a single machine in a specific way: in pair programming (or “pairing”), the two devs must swap between two roles:

• one at the keyboard, physically writing the code
• the other not at the keyboard, suggesting ideas and catching errors

The roles must be swapped on a timer, for example 5 minutes or 3 minutes, which you can set with a phone alarm or an application on the computer.

There are many situations in a sprint when pair programming is really useful.
Read on to find out how and when you can use it!

Advantages

Errors can be caught faster when you have two people looking at the code.
Two coders working together in this way will come up with ideas and potential solutions much faster.

It’s like instant code review.
The experience of the two developers is combined meaning better architectural decisions are taken.

The alternating timeboxes mean that a developer can’t get stuck with a problem for long periods with no new ideas.
No-one loses focus on the work, and both developers keep contributing.

Disadvantages

Since pair programming requires full focus, the two devs should ensure they take regular breaks.

So when should you use it?

Conceptually complex tasks

Pair programming can really improve your performance on conceptually complex tickets, because these are the ones where the number of details is so large that a single developer would be significantly slowed down and have a higher probability of making mistakes.
Having another developer on hand reduces these problems.
For example, when integrating a new payment provider with a backend server and a frontend app, the number of details is immense and could be ameliorated by pairing.

Speeding up important tasks (e.g. the sprint goal)

In order to prioritise the sprint goal, when the sprint backlog is empty but there are still sprint-goal-related tickets in doing, developers should pair on the sprint goal tickets rather than taking tickets from the product backlog.
This brings the full development power of two devs to bear on the most critical work in the sprint.
The exception to this is if a single dev is particularly well-placed to do the tickets and would be slowed down by pairing - in that case, that dev should tackle the sprint goal.

Training

Pair programming is extremely useful for onboarding new developers - whether new to Theodo or new to a team.
A more experienced developer can pair with a trainee to quickly and effectively share knowledge of the project and general coding skills.
Pairing helps the trainee stay engaged and ensures they write code themselves, instead of leaving the work to the experienced developer.
When pairing for training, it is particularly important to respect the timer.

A good balance is for the trainee to pair in the morning and tackle tickets on their own in the afternoon.

Help

When a developer needs help with a specific issue, they can ask another developer - for example their coach, the architect on the project or any developer who knows about the issue, or indeed any developer - to pair with them.
Knowledge can then be shared fluently.
Even pairing with a developer with no specific experience in the project can be useful as they may catch errors you have missed, or bring fresh ideas.

Bottlenecks

When there are more developers available than tickets available (e.g. in the case of dependency chains, or blocked tickets), pairing can allow the full power of multiple developers to be focused on the available tickets.

Knowledge-sharing

Pairing is great for the express purpose of sharing knowledge of a new feature - a developer working the sole ticket implementing new functionality can ask another developer to pair so that the second developer also learns the additional information that is being introduced to the project.
This is important to maintain a cross-functional team, which is necessary for a scrum dev team.

Interviewing

Pair programming is a revealing way to gain an insight into candidates interviewing for the role of developer.
When you pair with someone, you can assess their knowledge firsthand, see how they react to new knowledge, and experience their style of communication and coding.

Conclusion

Pair programming is a great solution whenever you need to do a complex ticket, speed up an important ticket, train a new dev, help or be helped by another dev on a technical issue, get past a dependency bottleneck in a sprint, share knowledge in the dev team, or conduct a technical interview.

Since these situations arise in every project, and potentially in every sprint (e.g. the sprint goal will always be an important task worth prioritising), you should pair whenever possible in these situations.
Pairing helps everyone in the team get to know each other, builds team spirit, and makes working together on the same task more engaging!

It would be great to hear from you - post any interesting experiences or use-cases of pair programming in the comments below!