Pair programming is two programmers working together at one workstation.
Formally, one programmer is the driver and writes code. The other is the observer or navigator who reviews each line of code as it is typed in.
Informally, they sit together on one code base and talk about stuff and break problems down. Either of them can write code and neither of them does anything else like checking the phone.
Pair programming is widely adopted by some organizations and shunned by others. It is always a topic for debate and people will have their preferences. We are all humans and there are times when almost everyone can benefit from pair programming.
Yet, it seems like an ineffective use of resources. We have two programmers. They could both be building different features for a week, at the end we will have twice as many features. But this isn’t the case and you may well end up with 2 sets of 95% done features that can’t be shipped. Programming together can increase the net amount of actually complete features you ship.
Fewer Mistakes and Bug Hold Ups
We’ve all had crazy hard bugs. These can be from fundamental flaws in the entire approach or a typo, an incorrect install or the need for a reboot.
As a team, the chances are that one of you has made a similar mistake before. Or it is likely that one of you knows someone else that has encountered the problem. And you are more likely to allocate the correct time to a problem before going back to the drawing board.
You can discuss better strategies. This is better than keeping the problem hidden all day without sharing it with others.
Easier to Keep Going — Moral support
Often working as a team can increase positivity about a problem. When someone shares a problem you are going through, you feel less defeated and more positive about trying again and again and again…
Harder to Procrastinate
Working as a team means you can’t stop and check your Email, Slack or Whatsapp for any desired distraction.
This seems like a small thing. But you can quadruple the number of hours a coder spends in the editor and coding, instead of sitting at a desk eating up hours of the day until time to go home.
Shared Best Practices
Coding together is a great way to share knowledge in your company. Coders can give each other tips as they go along to improve their approach and increase their speed.
Working together may uncover knowledge that may not be in your New Employee Handbook.
New employees can get up to speed much faster by pairing with an experienced team member.
Identify and Reduce Bad Hires
It can help identify bad hires early on if someone isn’t the right fit for a business or was hired for the wrong role. You can do something about it early on before you waste both parties’ time.
During a hiring interview, a team familiar with pair programming will be better at assessing if the candidate can program with others. If the normal guy who conducts interview sessions is absent, you can be confident that someone else can replace him and give a fair analysis.
Increase Employee Satisfaction
Coding together may bring employees closer as they share experiences and have more subjects to talk about. When other people understand what you’re up to you’ll have more in common. This can affect a lot of important business areas. It can even improve the topics of conversation at lunch to reduce employee churn.
Coding can be a lonely pursuit when you are behind a computer alone and told to produce features. Reducing any alienation in a company is important. This is one reason I’d suggest having a system of pair programming for early-stage start-ups as well as big enterprises.
Issues — When Pairing Goes Bad
Pair programming can mess things up and needs a sensible approach.
Don’t Overdo It (or Under do it)
Forcing people to spend all day together isn’t sensible and they may well end up hating each other.
1.5–2.5 hour bursts usually works best. Less is too short and it’s a waste of time.
Reward Shared Contribution
If you’ve given important deadlines to two programmers and then assign one to help the other with his task, you’re heading for a potential disaster. When you review who’s completed their tasks and one feels like they’ve done nothing, the personal metrics suffer. Mentally this is bad. But if it’s linked to any reward system you are shooting yourself in the foot. As a scrum master you need to make sure you account for pairing and assign tasks fairly.
More coffee and pairing up is not always the answer. When you’re tired and stressed you might not be communicating properly.
This can cause more problems in the code and between each other. Some people perform better this way and some don’t so you may be taking a risk.
Complex Code — Pair-up or Discuss
For more complex code it might be a distraction trying to pair together. Sometimes sitting down and explaining the problem can be more beneficial.
Formally sitting down together and writing code line by line could actually be distracting.
But what about Remote workers?
Employees working remotely can pair program with online screen sharing tools. I’ve debugged friends code in Brussels while sitting in a cafe in Kazakhstan. Trust me it’s possible.
These are reflections from my experiences. I’ve perceived these benefits while working with various businesses and different bootcamps.
As a scientist I accept that I’ve never done a double-blind trial on the benefits. Of course it’s never been a big enough priority compared to just getting stuff done.
But I would love a study with over 100 participants working on the same set of problems. One group of 50 could work in pairs and the other group could work solo. I’d like to see what happens. It could be a nice study for any computer science professors to do.
So as you can see I’m a fan of pair programming. Some coders don’t feel it’s an effective use of their time. If you’re a manager it’s up to you to assess the situation and make the most of your team. Either way, it is definitely something all companies should allow for at times.
It should be implemented dynamically rather than enforced. Any boot-camp should incorporate it into their course to build a well-rounded coder.
We use it often in my own dev agency, from tackling our hardest issues to on-boarding new staff. It’s a process we enjoy using to boost performance and knowledge across the company. Of course, we don’t enforce it all day and every day! But we like it and we’re keeping it.
As the old saying goes “A problem shared, is a problem halved.”
I run a podcast on growth mindset and tech start-up. If you enjoyed this you’ll learn more by subscribing.
If you’ve used pair programming I’d love to hear your thoughts on it. What practices or tips do you use to decide when to pair or not?