Pair programming is a software development technique where two developers work together to write code.
One common analogy is to imagine you’re a pilot. You’re in charge of the overall direction of the plane, while your copilot is responsible for the navigation and can offer tips along the way. Every so often, your copilot takes the reins for a while.
With pair programming, two developers sit at the same desk – or screen share, as our remote-working developers do. The pilot writes the code (and is often referred to as ‘the driver’), while the copilot (‘the navigator’) reviews the code as it’s written. Every so often, the pair switches roles.
A recent study found that pair programming “improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable” than programming solo.
Our small team of developers often pair program, especially when working on complex projects like launching a new product.
Why we love pair programming at Cronofy
Everyone gets to learn
Sharing knowledge is an important part of self-development for every developer. When we teach a new skill, it helps reinforce our understanding of it while simultaneously helping someone else grow and acquire new knowledge. It’s a win-win situation.
It doesn’t matter what we do or how senior we are – there is always someone who knows something that we don’t. Being paired means having the opportunity to share knowledge, allowing the company and its development team to grow faster together.
Code quality is better and there are fewer bugs
It often takes multiple iterations of a code before it’s ready to go live, which can easily turn a day’s worth of work into a week’s worth of work.
When someone reviews code as it’s written, there’s less of a need for so many iterations – errors can be picked up on as the code is written instead. This means that there’s less for QAs to pick up on, less bugs to fix later on, and overall less work for everyone.
Because of this, it reduces development costs and means that new products and features can be launched faster.
There’s less chance of programmer’s block
We’ve all had moments where we stare at a screen unsure what to write next, so we check Facebook or make a cup of tea. With pair programming, there’s less chance to get stuck because there’s always someone to troubleshoot with when you hit a wall. If you do, you’ll be able to bounce questions off each other and find a solution quicker.
It breaks up the pace
Staring at a computer screen writing code all day – no matter how much you enjoy it – can become lonely and repetitive. Switching up the pace can spark new ideas and stop the day from dragging.
Potential roadblocks
It doesn’t work for everything or everyone
There will always be instances when working alone is more efficient than working with someone else. It’s important to use pair programming only when it’s worth doing and not for the sake of it. For example, at Cronofy, developers don’t pair up every day. They do it when they want to share knowledge or work on a new product.
People need their own space
When two people are squashed together in front of a laptop or monitor for days, things can get cozy. You both want to see the screen, but you don’t want to get too close.
Instead of both hunching over the same laptop, you could use an external monitor, project the code onto a screen, or screen share. That way, you can both see what’s being written without things getting too cozy. You could even pair program remotely!
Management isn’t always keen
Sometimes the biggest roadblock you can face when it comes to pair programming can be from management. They don’t always understand why it’s more effective, or worse, they don’t believe in code reviews!
When you encounter someone like this, it’s important to relay the facts to them. The more facts you can give them about pair programming’s effectiveness, the more likely you’ll be to win them over.
Egos can get in the way
Pair programming only works if you can both communicate how you feel and what direction you think your project needs to take next. If someone doesn’t communicate well, or believes they know best, the project can fall flat before you’ve even started.
If you feel you’re working with someone who doesn’t communicate well, ask them to articulate their ideas in a different way. Keep asking questions until you feel that they’ve given you the details that you’re after. The more questions you ask, the more you’ll begin to understand where they’re coming from. If you can still ask ‘Why?’ or ‘How?’ to their suggestion, they haven’t given enough detail.
It’s important to not let ego get in the way when pair programming. However, when one person has more knowledge than the other, this can be a side effect. If someone within the pair believes that their way is the best – and only – way, ask them to explain why. Try to reason with them and explain to them alternative points of view. If you feel it will help, bring in other members of the team that can contribute to the discussion.
Conclusion
Much like Marmite, pair programming isn’t for everyone.
However, it’s becoming increasingly common in developer-led environments because of the many benefits that come with it.
Having someone who can offer support and with whom you can brainstorm ideas with helps to prevent procrastination. It also helps get the job done quicker and more efficiently, and who doesn’t want that?
Have you adopted pair programming into your development team? What works well for you, and how do you think things could be better? We’d love to hear how you feel over on Twitter!
