It is quite easy to see pair programming as using double the resources for writing the same piece of code. If wrongly applied, this might even be the case, so why do experienced pair programmers feel like it is more efficient than working on their own? Let’s take a look at the efficiency of pair programming if you want to give it a try on your engineering team.
The first possible issue with pair programming (and changing the way you work in general) is that it comes with an improvement ravine. Doing something in a completely different way takes some effort to get used to and to get good at it. There are a lot of small things you can do to make your pair programming sessions productive and enjoyable, but in the end, it takes some practice before it starts paying off.
When your team gets the hang of it, it will become a super valuable tool though, and you’ll notice that pair programming does not halve the productivity of developers.
that would be true if the hardest part of programming was typing— Martin Fowler
Research has concluded that the loss of productivity is not a 100% increase in used working hours, but instead approximately 15%. This might still seem like a significant cost, but the benefits of pair programming greatly outweigh this.
What makes pair programming efficient?
A short feedback loop
A lot of popular programming techniques resolve around shortening the feedback loop between writing code and finding out there are mistakes in it. Test-Driven Development is one of the more popular ones. The shortest possible feedback loop your team will experience will be while pair programming. Waiting for code reviews or running automated tests will always take some time but having someone sitting next to you will result in receiving instant feedback.
Increased quality
Pair programming greatly reduces the number of bugs introduced in code. Only bugs that both the driver (who is writing the code) and the navigator (who observes) would miss get through and the navigator can also help in writing meaningful unit tests that might otherwise get missed.
The resulting design of your software will also be better because the chances are higher that you’ll interrupt your flow to discuss different approaches. The navigator could help think on a higher level while the driver is more focused on the specific tasks at hand. This improved design will help to make changes to your software faster and safer.
Knowledge sharing
When working solo, it is quite easy to build knowledge silos. Having a process that contains code reviews already helps here, but working on something together ensures that at least two people know how everything works inside-out. This makes it less problematic if an engineer gets sick or leaves the project, especially if you switch pairs regularly and spread the knowledge even further.
Next to that, you’ll also see how other engineers tackle problems and what tools they use for it. Using pair programming during onboarding can reduce the learning curve for new engineers a lot because they get to know the processes and the code way faster. Junior profiles can also grow a lot faster when being put together with more experienced profiles, but also the other way around.
Focus
When working together on one task, it makes it easy to focus on working towards the end goal, especially if you snooze notifications and only bring one device. You will also be less easily distracted during the seconds it takes to run your test suite.
This can make pair programming quite exhausting though, so it’s crucial to manage pair programming sessions well. Take enough breaks (f.e. using the Pomodoro technique) and don’t apply it in situations where pair programming does not add any value (such as repeating jobs) to keep the added focus and quality to its maximum.
It’s fun
It takes some practice to get used to it, but once you have a process containing pair programming, your team will feel like it accomplishes a lot more while learning faster and getting to know their colleagues better. Collaborating that closely really makes you feel like you’re part of a team.
Conclusion
It might take some practice time to get super productive doing pair programming and to learn how to identify which jobs it might be useful for. After crossing that learning curve (which should only be a matter of days, maximum weeks), the advantages greatly outweigh the cost.
So I’d advise every team to at least give it a spin, you’ll probably find much value in it.
Member discussion