Arya and Sansa. Han and Chewbacca. Harry and Ron. When people team up, great things can happen.
What is pair programming?
Pair programming, an Agile approach to software development, involves two programmers working together at the same workstation. One programmer (called the driver) writes code while the other programmer (called the navigator) reviews code in real time. Pairing sessions can accelerate Agile delivery, because teammates work together to find the best solutions to several challenges.
Rather than working in silos, team members work together to share knowledge and quickly move through obstacles. Sounds good, right? Well, some organizations view pair programming as an inefficient use of time. After all, why should two developers work on the same piece of code when there’s a mountain of technical debt, an impending release, and lingering OKRs around the corner?
How to get started with pair programming
The key to any successful paired programming partnership is open communication and creating a plan together so you can avoid bottlenecks during the project process.
Here are a few things you need to consider as a team before beginning any coding work:
- Have a mutual understanding of what “ready” looks like for this project. Consult each other as well as any stakeholder involved, like a product owner, so that everyone is clear on when to give the projects a final green light.
- Create a step-by-step project plan. Consider how you will trade off coding and reviewing responsibilities, how you want to handle testing, and any other external help you may need to complete the project.
- Brainstorm as many potential roadblocks as you can think of in this planning process, and try to come up with potential solutions. You can brainstorm together on paper, talk it out, or go off separately and then share thoughts, but this is an important step. Always be prepared!
- Agree on the technology you want to use. From computers and keyboards to reliable wifi or a whiteboard, make sure you have all of the tools you need.
Some pair programming best practices
To achieve the best outcome of your pair programming experience, we recommend you follow these best practices:
- ABC (Always be communicating). Regardless of whether you’ve worked well together in the past or you’re a brand new partnership, the importance of communication can’t be overstated. Two individuals are likely to have different thoughts and opinions along the way. To keep the project (and yourselves) from suffering, establish open and frequent communication practices early.
- Take turns. No single person has to be the only one navigating or driving, and you shouldn’t. Take turns in each role as often as you need to make sure your minds and eyes stay fresh and you keep producing quality work.
- Take a break. Rome wasn’t built in a day, and neither was coding. You and your pair programming partner need to make sure to take breaks so as not to induce burnout.
- Get good technology tools. And remember to click that video on. Oftentimes, pair programming is done remotely. It can help to have an actual facetime conversation, even if it’s virtual, to stay connected and communicative throughout the course of the partnership.
- Ask for help. If there is a part of your project that both of you don’t understand, ask for clarification. Better to ask ahead of project completion than after.
The case for and against pair programming
There are benefits and drawbacks to pairing sessions, so a few GitLab team members shared their thoughts to help you determine whether pair programming is right for you.
“I've done pair programming in the past. I love it because it helps to bounce ideas off people, and I find we often could solve ‘bigger’ problems faster. To me, the downside is measuring/proving that this is a good method of programming since many people see this as inefficient (two people working on the same problem).” – Cynthia Ng, senior support agent
Today’s developer feels the pressure of delivering at rapid speeds. Sometimes, a challenge is just too complex for one person to solve, and pairing sessions can help alleviate the difficulties experienced when racing towards a release while carrying a burdensome issue. Talking through solutions and drawing on each other’s experiences can help a pair work towards a new approach.
Measuring the effectiveness of pairing sessions might be difficult, but there are ways to evaluate success. Considering failures in functionality, the number of bugs, and improvements in productivity can help teams determine whether pairing makes a difference with delivery.
The role of engagement and continuous learning in delivery
IT leaders may be reluctant to embrace pairing, since two developers dedicate their time to a single problem, but it’s important to note researchers have found that 90% of new skills learned are lost due to lack of engagement, and in an Agile framework, a culture of continuous learning helps improve all aspects of delivery.
“When I was a junior developer, I found it very helpful to talk through my thought process and hear how senior developers approached the same problem. But, as an introvert, I found it exhausting to do all day, every day.” – Jennie Louie, test automation engineer, Enablement
Agile models often include the value of continuous learning to help everyone – from C-level to junior level – develop new skills to remain adaptable and productive. Pairing sessions provide a platform from which teammates can learn in tandem.
“I’ve never done ‘strict’ pairing with a driver/navigator, only the relaxed kind where you just chat and sometimes switch keyboards. And while I can't really imagine pairing full-time, I guess with the right pair and some practice it could indeed be a great experience.” – Markus Koller, backend engineer, Create:Editor
The drawbacks to pair programming might make you hesitate, but I encourage you to take a chance on it, especially if you want to accelerate delivery. Here are a few pros and cons of pairing to help you understand the process:
Advantages of pair programming
Directly collaborating with a teammate can increase morale and inject fun and diversity in one’s day. By working alongside each other, teammates can learn different coding practices, workflow techniques, and new ways of approaching problems, which increases innovation and efficiency and decreases knowledge silos.
“Pair programming can be great for onboarding, mentoring, and rubber ducking difficult problems, since teammates receive immediate feedback.” – Andrew Kelly, senior security engineer, Application Security
Junior developers benefit when pair programming with senior developers, since they’ll gain strong industry knowledge. Meanwhile, senior developers get teaching experience and the ability to think critically about solutions.
“Programming is fairly abstract. When you have to explain a concept verbally, it often makes you realize you're missing pieces or that there are better ways to solve problems than your initial idea.” – Brandon Lyon, marketing web developer/designer
Regardless of experience level, everyone can benefit from pairing sessions, since there is no right answer in programming. I consider software development a multi-faceted endeavor in which imagination and creativity are driving forces. Based on knowledge, experience, and learning styles, people approach some aspects of code with a different understanding of how it ties into existing systems. When pairing, people can discuss these perspectives and assess which approach is best.
Disadvantages of pair programming
Pairing might sound like the solution to many of your delivery problems, but it’s not all roses and rainbows.
Given the success of pairing, teammates might be tempted to join forces a little too often. Pair programming can feel inefficient if overdone or used for tasks such as boilerplate code, smaller and well-defined changes, and yak shaving.
“Pair programming is not a silver bullet. Some software solutions just need a single person to hunker down and work it out before sharing with others.” – Andrew Kelly
If teams are just starting out with pairing, it can take practice and patience to be a “good pair,” which can be difficult even for experienced pair programmers. Do retros after a pairing session to understand what worked well, what didn’t work, and how you can improve future sessions.
See it in action
Now that you know a bit more about pair programming, you might feel ready to take the plunge. At GitLab, we 💖 pairing. Most pairing sessions occur when developers work at the same station, but as an all-remote company, we’ve found ways to make it work.
“Remote pair programming can be tougher than in-person pairing. Distance plus the tooling isn’t always the best, but it’s not impossible.” – Andrew Kelly
GitLab’s Support team created a dedicated project and issue templates for pairing sessions.
“In Support, we do pairing sessions (or group ‘crush sessions’) and find we often get through more tickets when working together, so it's something we're tracking as a milestone for each quarter.” – Cynthia Ng
Over in engineering, the Frontend team has also been experimenting with how to support pair programming. The team has used VSCode live share a few times but enjoys open discussion and sending patches to each other.
“The best format so far is someone posts a "🍐 request" in the #frontend_pairs Slack channel – people show interest – a time is scheduled on the calendar – then we do somewhat of a mob programming session.” – Paul Slaughter, frontend engineer, Create:Editor
Every software team hears the importance of acceleration, and it can be a daunting thought, especially when faced with complex problems. The next time you find yourself dragging your fingers across the keyboard and dreading that next line of code, consider pairing up with a teammate to tackle issues together.
“Pairing will look different for everyone. Anything that encourages communication, engaged knowledge sharing, and breaking our engineering silos is good.” – Paul Slaughter
Cover image by Jonathan Mast on Unsplash
