What is pair programming?
Pair programming is an activity where two developers work simultaneously on the same coding task. It’s an agile software development concept that originates from Extreme programming methodology, first popularized in the 1990s.
Practically speaking, pair programming is based on the four-eyes principle or the idea that ‘two heads are better than one.’ When developers write code in pairs rather than alone, they can collaborate on tasks, share knowledge, discuss ideas in real time, and problem-solve on the go. The goal is to create better quality code, unify the development team, and create a more robust, innovative product overall.
How does it work?
Traditionally, two developers shared a single computer and took turns writing or reviewing code. However, an estimated 66% of global software engineers now work remotely, meaning modern-day pair programming sessions often occur online.
In a remote pair programming session, one developer shares their screen (displaying the IDE or code editor) and writes the actual code. Meanwhile, the other developer provides guidance on what to write or reviews what is being written. That’s the basic dynamic. However, variables like the style and types of pairings often affect the structure, flow, length, and purpose of a pair programming session.
At Railsware, we’ve been practicing pair programming since our inception. Over the past 16 years, we’ve seen the positive effects that pair work has had on individuals, the team, and the company overall. It’s what inspired us to expand this practice to other software development activities and internal functions.
A job of an engineer isn’t just to write code. You also spend time planning your work, discussing solutions, debugging, testing, evaluating requirements, and many other things on which you spend your workday.
In my experience, we practiced pairing on almost all of these activities, and it worked well.
Artur Termenji
Full Stack Engineer
P.S. We share our experience with building sustainable remote collaboration workflows in a separate post.
Code review vs. pair programming
Code (or PR reviews) and pair programming are completely different practices (although equally important to the Lean software development process, we’d argue).
Usually, a PR review is carried out asynchronously. An engineer checks the pull request submitted by one of his teammates, and either approves it, or informs their teammate of any issues that require attention.
On the other hand, pair programming takes place in real time and isn’t exclusively focused on code analysis. Engineers don’t systematically review each line of code that is written during a session, although they do pay close attention to the quality of the work being produced.
Sometimes, depending on the seniority of engineers, pair-programmed code is approved and merged on the spot. But it’s also common for pull requests that were shaped during a pairing session to undergo an independent code review.
Types of pairing in pair programming
There are three main types of pairings, made up of the following roles:
- Expert: a programmer proficient in the project’s tech stack, codebase, and domain knowledge.
- Novice: a newcomer, someone with little or no programming experience, and/or unfamiliar with a particular technology/domain.
Popular pair programming styles
This style mimics motorsport where the Navigator sets the course and the Driver follows their instructions. So, in pair programming, the Driver controls the keyboard and writes code based on the Navigator’s guidelines.
The biggest advantage of this style is that it enables the pair to assess an issue on both a micro and macro level: the Navigator concentrates on the bigger picture while the Driver works out the details. For best results, the Navigator should provide broad instructions, and let the Driver decide how to implement the solution.
The Driver/Navigator style can be successfully applied by all pairs we described earlier. It is most effective in the Expert-Novice pair dynamic, where the Expert takes the role of the Navigator.
Ping-pong
Teams who follow the Test-Driven Development technique often use the ping-pong pairing style. Here’s how it works: One developer writes a failing test and the other writes the implementation to make it pass. Then they refactor the code together (if necessary), and repeat the cycle.
Usually, the pair switch roles throughout the session, especially if they are both Experts and have an equivalent skill level. This style works well for all kinds of pairings and can be very effective when two Experts pair together.
Tour guide
Here, one programmer assumes the role of a ‘Tour Guide’ and the other becomes an ‘Observer.’ The Tour Guide writes the code and explains his decision-making process, while the Observer watches the screen and listens.
After a short coding round, the Observer is invited to comment on both the written code and decisions made by their pair mate. Once they have refactored the code, or resolved any issues or misunderstandings, the pair move on to the next coding round.
This style is ideal for Expert–Novice pairs. When the Expert is the Tour Guide, they can run an onboarding session without constant interruptions, yet easily provide opportunities for the Novice to ask questions and contribute. When roles are reversed (Novice as the Tour Guide), the Expert gets to understand the junior developer/newcomer’s thought process and provides feedback in between rounds.
Strong pairing
This style is best suited for Expert-Novice pairs, where the Expert essentially tells the Novice what to do. It’s helpful for scenarios when a senior developer needs to teach a junior how to solve an issue ‘the right way.’ It also pushes the Expert to consider the viability of their idea while they’re in the process of explaining it.
However, because this style is heavy on the ‘thinking out loud’ aspect of pairing, Experts may struggle at first. Engineers typically work alone and make decisions on the fly, not always considering the ‘why’ behind their choices. As such, strong pairing tends to push engineers out of their comfort zones.
Lastly, unlike all the rest of the styles we’ve discussed, the Novice is always the Driver in strong pairing scenarios, and the Expert is always the Navigator. They never switch roles.
Unstructured
In unstructured pairing sessions, programmers don’t follow any fixed collaboration style. Oftentimes, these meetings are ad-hoc, initiated when an engineer is dealing with a persistent bug or tricky task and needs help from a trusted peer.
During the session, they may switch roles occasionally and prefer not to follow any plan/agenda. Most unstructured sessions happen between Expert-Expert pairs. On the other hand, this style isn’t well-suited to Novice-Novice pairs, who have less experience in running pairing sessions and would benefit from following set rules.
Benefits of pair programming
Better solutions are produced
Again, when it comes to problem-solving, two heads are usually better than one. Whether the pair is tackling a stubborn bug or discussing improvements to the system architecture, engineers can discuss the issue in real-time and brainstorm ideas as they go.
Certain pair programming styles (like Driver/Navigator) also ensure that an idea or piece of code is examined from two perspectives: the big picture, and the smaller details of implementation. In our view, this empowers engineers to create smarter, more well-rounded solutions.
Tip: For finding solutions to larger, more complex problems, our product teams often use the BRIDGeS framework.
Faster onboarding and knowledge sharing
Development teams can’t afford to spend weeks waiting for a newcomer to get familiar with the codebase and documentation. Left alone, a new team member may lack context and struggle to complete their first assigned tasks. That’s why it’s more efficient for an Expert (say, a senior developer) to initiate a pairing session with the newcomer at the beginning of the onboarding period, and dedicate a couple of hours to knowledge-sharing e.g. explaining shortcuts/intricacies in the documentation, providing product context etc.
Prevents the accumulation of technical debt
A gradual build-up of technical debt can be detrimental to any project, and development teams must work together to prevent it. In our experience, pair programming makes it easier to spot the seeds of tech debt. With two pairs of eyes on the screen, engineers are better equipped to identify (and fix) bugs as they appear. And since the thinking/writing process involves more than one engineer, code quality and structure also improve.
Igor Dobryn
Full Stack Engineer
From a business perspective, there are two things that matter the most – code quality and speed of code delivery.
When the team does PR reviews, engineers get feedback from their teammates. But pair programming goes one step further – it allows engineers to get feedback during the process of writing code, so they can improve their work on the fly!
Not only does this practice save time, but having two sets of eyes on the code ensures that engineers deliver high-quality work week after week.
Helps programmers stay focused
In a well-structured pairing session, each programmer is expected to contribute (on some level) to the task/discussion at hand. The constant back-and-forth of these sessions means there are fewer opportunities for distraction: Slack notifications, emails, phones, etc. Additionally, pairing sessions are often dedicated spaces for resolving blockers or difficult tasks. Two engineers can put their heads down and potentially solve a problem within 2 to 3 hours, rather than over several days. For optimal efficiency, companies can often use employee tracking software to monitor and manage their pairing sessions.
Promotes collective code ownership
When developers regularly work together on a single task, it fosters a sense of shared ownership of the codebase. Collective ownership also boosts accountability, making engineers less likely to take shortcuts or allow sub-par code to slip through the cracks.
On top of that, pair programming usually gives team members the chance to work on different parts of the product, not just the elements they personally created. This prevents the so-called ‘bus factor’ effect, where the team is left in the dark after a key player leaves the project.
Effective tool for hiring and retention
When hiring a new team member, we usually run a ‘full day’ interview where one of our engineers coordinates a pair programming session with the candidate. This type of collaboration helps us assess the candidate’s strengths and weaknesses, and understand how they communicate ideas, cope with feedback, and respond to imperfect requirements, tech debt, etc.
Meanwhile, we find that pair programming helps us retain the best talent too. In the realm of remote work, having a good pair mate reduces the risk of people leaving as they feel more connected to the team and, in turn, the company. Using any of the Meta Workplace alternatives can make this connection even stronger by supporting seamless collaboration and communication. A pairing session isn’t just about coding. It’s also about those shared ‘aha’ moments, small talk, offering a helping hand, bonding over mutual frustrations, and all the other stuff that builds team spirit.
Drawbacks of pair programming
Consumes additional time and resources
One study found that paired-up engineers spend 15% more time on a single task than if they completed it alone. So, while pair programming comes with a cost, we believe it’s pretty minimal. In our experience, investing in a paired session allows us to save the same amount of resources (or even more) on the QA process, as the code produced in that setting is of higher quality and contains fewer defects in the end.
It requires practice
Pair programming should never replace solo work; it should only complement it. But it may take practice and persistence to reach a point where pairing up feels natural to you. Practicing the art of thinking out loud, and working on your active listening skills, can help ease the transition.
It’s not for everyone
An engineer’s capacity to enjoy pair programming often depends on their personality. Some people prefer working alone, while others thrive in a collaborative setting. Not to mention, it can be stressful working in an environment where you have to maintain a high level of concentration over a prolonged period, even when breaks are factored in.
It’s exhausting
Not only can pair programming be stressful for some, but it’s a fairly exhausting activity too. Working side by side, commenting on every step, explaining technical concepts and decisions, finetuning the details – all of these things make pairing sessions extremely taxing. Beginners often struggle with the mental exhaustion that pairing brings, but as with anything else, the more you do it, the less difficult it becomes.
I find that pair programming is incredibly beneficial when I feel non-productive, blocked, and generally low mentally. Pair work makes me more energized and motivated to solve problems.
It’s easier when you share the problem with someone. I also believe that the right balance of pair work and working alone might prevent burnout.
Artur Hebda
Full Stack Engineer
Common misconceptions about pair programming
- It reduces team productivity. Again, while a major study indicates that the productivity of a single programmer is slightly reduced, pairing sessions can actually help the rest of the dev team save time (e.g. fewer bugs for QA to find, a smaller backlog to tackle). And another study found that novice-novice pairs were more productive than novices who worked alone.
- It’s only suitable for mentoring juniors. We believe any engineer, regardless of their experience, can benefit from a pair programming session. Even veterans of the project or company might be surprised by how much they can learn from a peer. In a nutshell, regular knowledge sharing helps engineers grow professionally and strengthens relationships between teammates.
- It’s a form of micro-management. Pair programming isn’t about double-checking the quality of someone’s work. And participants shouldn’t ever feel as though someone is looking over their shoulder, waiting for them to make a mistake. On the contrary, sessions should be supportive, educational, open-minded spaces where engineers aren’t afraid to slip up or voice their opinions.
We delve deeper into our hands-off team management approaches in the posts Holacracy in Action and Balance Between Authority, Responsibility, Accountability.
Do’s and don’ts of pair programming
Pro tips for pair programming sessions
- Keep talking. Many programmers aren’t used to thinking out loud, and they may dislike the practice at first. However, constant communication is key. If an engineer (particularly the one leading the session) stops talking, then that’s a sign something has gone wrong.
- Keep listening. Pair programming should be give-and-take, not a lecture. So, even the leader of the session should make an effort to listen to their pair mate’s ideas and opinions. But don’t let the meeting get sidetracked by interruptions – if you disagree with your peer, pause your work and discuss the issue separately.
Check out our post on effective communication for some universal tips on how to avoid misunderstandings at work.
- Avoid refactoring or doing other coding tasks during breaks. Again, regular breaks prevent burnout and are an important element of pairing sessions (especially remote ones). Don’t skip or work through them. Instead, chat with your pair mate, grab a coffee, or take a short walk before the next round.
Artur Hebda
Full Stack Engineer
I don’t do more than 2 or 3 hour-long sessions a day, and I still find those days exhausting. But they also make me feel like I’ve achieved more than I could have done on my own.
Having a single session longer than 3 hours a day would be too much for me.
Tools for pair programming sessions
Railsware is a remote-first company with our teams spread out over 25 countries. Despite the distance (or, rather, because of it) we practice pair programming regularly and rely heavily on it during our knowledge-sharing, hiring, and onboarding processes.
Over the years, our engineers have tested different tools, and stuck with:
- Visual Studio Code with Live Share plugin. This IDE and plugin combo allows developers to write code together by sharing parts of the code without sharing the whole repository access. We use it during “full-day interviews” with candidates who aren’t a part of our ecosystem.
- RubyMine with Code With Me plugin is our engineers’ go-to choice for remote pair programming sessions.
For screen sharing, we mainly use:
- Slack huddle. A handy tool that allows you to highlight text on the shared screen.
- Zoom uses less bandwidth, so it’s more suitable if your internet connection isn’t very reliable.
If your team is distributed as ours, we’d also recommend the Tuple app. Additionally, for coding work that doesn’t require an open browser, try using ssh with tmux, especially when working at lower bandwidths.
Final thoughts
We practice pair programming to solve project blockers, validate promising candidates, onboard new team members, share expertise, and distribute knowledge within the team. Although not without its vices, we believe the net benefits of pair programming far outweigh the drawbacks – especially when the practice is applied to remote working environments. Our last piece of advice? Don’t knock pair programming til you’ve tried it!
Curious about our other software development processes and approaches to product building? Check out our product development services page for a closer look.