What’s pair programming
Pair Programming is an activity where two developers are working together on the same part of code simultaneously. The main idea behind pair programming is to encourage two developers to discuss, plan, think through, and implement a better solution than each could invent alone.
Originally, the definition of the term also included “the necessity to share one machine.” However, modern reality shows that online pairing sessions can be as effective as physical ones. This is not a surprise for our team, though, as we have been a remote-friendly company that practiced pair programming all the time from the very beginning.
At Railsware, we saw the positive effect of working in pairs and expanded this practice to other activities.
A job of an engineer is not just writing 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
Types of pairing in pair programming
There are several types of pairing during a pair programming session that include the following roles:
- Expert – a person proficient in the project’s tech stack, codebase, and domain knowledge.
- Novice – a newcomer, person with little or no programming experience, and/or a person unfamiliar with a particular technology/domain.
Expert-Expert pair
This type of partnering is great for solving difficult problems and fixing blockers fast. It’s also very beneficial in terms of knowledge exchange. A session with two experts helps shape the technical and architectural vision and establish single codebase-wide approaches.
Expert-Novice pair
This session is mainly run for Novice onboarding and fast learning. During the session, an Expert can efficiently transfer knowledge about the project, domain, technology, approaches, and more. At the same time, an Expert can get a fresh look at a task from a Novice.
Novice-Novice pair
This type of pairing is the riskiest one as developers don’t have sufficient knowledge to produce high-quality code. This pair needs a supervisor, who would jump into the session when Novices face a blocker.
The most popular pair programming styles
The pair programming practice implies several styles participants can follow. Each of them suits different tasks and can have different benefits. Let’s consider some of the most common ones.
This style mimics motorsport where a Navigator controls the process and dictates instructions, while a Driver holds the wheel and follows the instructions of a Navigator.
In pair programming, a Driver is a developer who holds a keyboard and is focused on writing code using the high-level instructions of a Navigator. A Driver focuses on details, thinking through each line of code without necessarily seeing the whole perspective.
A Navigator is a developer who doesn’t write code but concentrates on the bigger problem picture. A Navigator should dictate high-level instructions without thinking about how to implement them in code and without judging the solutions a Driver came up with to implement the Navigator’s instructions.
The greatest advantage of a session lead using this style is that the issue is considered on micro and macro levels all the time by two people.
This pair programming style allows the developers to stay focused, share both tactical and strategic vision, and exchange knowledge more efficiently.
A Driver/Navigator style can be successfully applied by all pairs we described in the previous paragraph and is most usable in Expert-Novice pair, where an Expert takes the role of a Navigator.
Strong Pair Programming style
This style is the most suitable for Expert-Novice pairs, where an Expert basically dictates code and a Novice writes it down. It’s a very effective session to teach a Novice to solve some issues the way the expert would do it.
At the same time, the style is beneficial for an Expert too. When dictating code, an Expert has to think it through and say it out loud. It gives a developer an extra moment to make sure that the initial idea is workable.
This style also requires some practice from an Expert, as developers are more used to working alone and making decisions on the fly, sometimes without even realizing why the choice was made that way.
Unlike all the previous sessions, here, a Novice is always the Driver, and an Expert is always the Navigator. They don’t swap roles.
Tour Guide style
This style defines the roles of a Tour Guide and an Observer. A Tour Guide writes the code and comments everything at the same time. The Observer listens to the Tour Guide without commenting.
After a short coding round, an Observer can comment on the written code and chosen decisions. A pair can discuss the code, refactor it, and move one to the next coding round.
This style works great for an Expert–Novice pair. When the Expert is the Tour Guide, the Novice can better and faster understand the context of the project and learn by observing. When the Novice is the Tour Guide, the Expert observes and then shares thoughts on improving the code.
Ping Pong style
This style is used when a team follows the Test-Driven Development technique. One developer writes a failing test. Another developer writes the implementation to make it pass, then the pair refactors the code together, if needed, and proceeds to the next cycle, swapping or not swapping the roles.
This style works well for all kinds of pairs and can be very effective when two Experts pair together.
Developers can also use the Unstructured Pairing style, which is really no pattern at all, but rather switching turns, and that’s it. This style is effective if peers trust each other and aren’t confused by a lack of rules and structure.
Advantages of pair programming
At Railsware, most of the engineers practice pair programming regularly. For us, it’s a workable approach with proven benefits for both businesses and engineers. Here’s what we get when working in pairs:
Better solutions are produced
The quality of the code that was created in pairs is higher because:
- When a small piece of code is written, developers review the code, refactor, and fix bugs immediately.
- Code is better structured, as there were two engineers who discussed the structure first, pondered it, and then created it.
- Code/issue was constantly considered from two different perspectives – closer (a Driver sees all the detail) and a high-level one (a Navigator seeks to see the bigger picture).
Faster onboarding and learning
A spare pair of hands can be crucial for a team, so newcomers should get into the project fast. A pair programming session provides perfect conditions for fast and efficient onboarding of new team members.
Artur Hebda
Full Stack Engineer
Newcomers appreciate when they are shown the shortcuts in the documentation because, over time, there might be too much documentation which is hard to read and remember. During the pair programming session, I can go through the documentation with them and tell them the summaries of the most important things.
Some newcomers learn faster when they are left alone after being pointed towards the relevant parts and doing the reconnaissance on their own. They enjoy this more than just reading the materials.
Pair programming allows both newcomers and a team’s long-livers to receive new knowledge faster when guided by an experienced developer.
Collective code ownership
When several people are working on one task, they all feel involved and share ownership of the codebase. All these engineers are familiar with different parts of the product, not only with the parts they personally created. And when one engineer leaves the project, there’s no so-called “bus factor” effect when one person in the team holds the necessary knowledge and all the rest are out of context.
This benefit gets even more obvious when peers rotate and more people are involved in the work on one particular feature.
Effective tool for hiring
When hiring a new team member, we usually practice a “full day interview.” During this day, a candidate has a pair programming session with one of our engineers working on tasks from real projects, commenting and explaining their work. We stick to this method because:
- It’s a reliable way to see how the collaboration goes with a candidate.
- It allows us to assess what the candidate is good at and what needs to be supercharged.
- It gives us a feeling of how candidates communicate their ideas, objections, how they respond to the imperfect requirements, tech debt, etc.
Effective tool for retention
In the realm of remote work, having a good pair mate might reduce the chances of people leaving as they feel more connected to the team and hence the company itself. A pair programming session is not only about coding but also shared “aha” moments, small talks, jokes, solved issues, mutual help, synergy, and much more. All these moments create an affiliation with a team. Pair programming with rotated peers increases this bond and creates team spirit that distributed teams often lack.
Knowledge sharing
In a pair programming session, experts get a chance to transfer their expertise and knowledge to others. It’s especially useful when the team can’t meet in person.
Efficient work
When working together and staying focused, developers don’t get distracted by Slack, emails, phones, etc. Another aspect is that the team gets a chance to resolve blockers and some really difficult tasks more quickly.
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
Disadvantages of pair programming
Now, let’s talk about the drawbacks of practicing pair programming for businesses and engineers.
It takes more resources per task
It may seem that two developers working on the same task consume more resources than if they worked separately on different tasks.
However, it was estimated that together developers spend 15% more time than if the task was performed by one developer. Our own experience has also shown that the time losses are minimal. We believe that by spending a bit more time on a paired session, we save the same amount of resources (or even more) on the QA process, as the quality of the produced code is much higher and there are fewer defects in the end result.
Igor Dobryn
Full Stack Engineer
From a business perspective, there are two main things that matter the most – code quality and speed of code delivery.
As for quality, everyone does PRs reviews (if you don’t, you should). When the team does PRs reviews, developers get feedback from their teammates.
Imagine you get this feedback instantly during the coding process and can improve code on the fly! First of all, it saves time. Second of all, there are two people who are focused on one piece of code, so it also improves the quality of the code delivered.
High stress
High cognitive load is not only tiring but stressful as well. And it’s not only the pace and extreme concentration that make pair programming stressful. Some developers feel stressed when they need to talk about things they don’t know openly.
It requires practicing and learning
It’s essential for engineers to think and work alone. Pair programming is about thinking in a loud mode and commenting on every single idea. It takes some time and practice to get accustomed to it. But after a while, you may even enjoy it.
Rapid fatigability
When working side by side, commenting on every step, discussing all the details, and explaining things, your brain consumes more energy if compared to a more relaxed work on your own. This is why, after a two-hour session of pair programming, you might feel exhausted.
Artur Termenji
Full Stack Engineer
I think when you work alone, you have lots of distractions, like Slack messages, someone or something outside, or even, you know, opening a second browser tab and reading something different. You have lots and lots of those tiny distractions during your day.
When you pair, you cannot afford that. You work for an hour, concentrate as much as possible, then you have a short break, and repeat everything again. Perhaps it’s the reason why people get tired more during pair programming.
Dos and don’ts in pair programming
If you believe pair programming is exactly what your team lacks, then here are the things you should and shouldn’t do in pair programming.
What to do in pair programming
- Choose a tool. Choose a tool for the session you both feel comfortable with. Before the session, find out what environment and tools your peer uses in their everyday work. The choice should satisfy both parties and be familiar to both of you. Take some time before the session to set everything up. This point is critical for an online session not to waste time when the session starts. More on tools you can use for a remote team, we’ll talk about later.
- Find the time. Pair programming is a tiring and stressful practice, so the right timing is important. If you are in the same time zone, discuss with your peer when you’re the most productive throughout the day. If your peer is in a different time zone, find overlapping hours, and choose the time slot that is free of meetings.
- Plan beforehand. Before the session, you can schedule a short call with your peer to discuss the task and make sure you have a single vision of its purpose. Choose tools, approaches, and technologies to solve the task. Break the work into a handful of steps and prioritize them. This way, you’ll get an actionable plan and will know how to start your session.
- Choose the pair programming style. In some cases, the choice may seem obvious, whereas, in others, you’ll need to decide on what strategy is the best for a particular case, depending on the task and your peer.
- Keep talking. Thinking out loud might be challenging if a developer isn’t used to doing it. However, constant communication is the key. If one of the partners stops talking, that’s a sign that something has gone wrong.
- Keep listening. Talking is not enough. It has to be a dialog, so listen to your partner’s ideas and comments to maintain communication. If you disagree with your peer, make a pause to discuss it and find common ground.
- Be open. Pair programming sessions might feel unusual and uncomfortable at first. Yet, you should remember its purpose and main goal. You need to gain the trust of each other to work in synergy.
- Be patient. Your peer might work slower or faster than you. If you feel like interrupting a person, use a 5-second rule (wait for 5 seconds – if you don’t change your mind, you can comment)
- Ask questions. Don’t be embarrassed to ask many questions. Your task is to understand the ideas of each other. Clarify why your peer offered this or that approach, so you can apply it further when you swap roles.
- Take breaks. Pair programming is hard, so take regular breaks to refresh. You can use a Pomodoro technique, meaning you work for 50 minutes and then have a break for 5 minutes. We recommend a 50-minute session, a 5-minute discussion, and then a 5-10 minute break.
In our team, the onboarding process is an introduction to the project structure and conventions, but at the same time, it’s a deep dive into pair programming. Usually, it’s the first contact with pair programming practiced daily, and thus it’s met with some skepticism and viewed as an unuseful quirk and overkill.
Given some time, engineers notice the benefits it gives. Having two minds on the task produces a higher quality of the outcome and less need for future refactoring. The decision-making paralysis is nonexistent, and it’s just smoother to go over all the tiny choices you make every day with another engineer on your side.
You also can adapt this process to your circumstances. In my case, it’s an async pair programming where you don’t spend the entire day coding together because of misaligned schedules. Instead, when being alone, one leaves questions and thoughts next to the code, making it easier to take over by the partner at any time.
Marcin Horosz
Full Stack Engineer
What not to do in pair programming
- Don’t give up if pair programming is a new experience for you. Working in pairs is more difficult than working alone, and it’s natural that you can feel out of your comfort zone. The only rule here is to keep going, stay positive, and open-minded.
- Don’t start without a plan. You’ll lose precious time discussing details instead of a productive coding session. Start coding without a plan is also a bad idea, as you may have different visions of the future solution and are very likely to face misunderstanding.
- Don’t stay silent. Yes, pair programming may be new to you. However, your peer needs to understand the flow of your thoughts. Otherwise, she won’t be able to continue working on this piece of code.
- Don’t continue when you start losing focus. Ask for a break, rest for some time, or cut the session short if you understand that you can’t continue productive work.
- Don’t push on your pair mate. It’s especially vital for Expert-Novice pairs where one peer is much more experienced. Don’t push on your partner. It’s very likely that it’s the first session for the Novice, and they are already nervous.
- Don’t get distracted. Of course, you can’t guarantee that during the session your thoughts won’t flow in another direction. At the same time, you can minimize distracting factors, make sure there are no upcoming meetings in your schedule, turn on “do not disturb mode” in Slack for the session time, and put your phone somewhere far away from you.
- Don’t do refactoring or other coding while breaks. Breaks are to help you take pressure off, distract, have a small talk with your peer, and get some energy before the next round.
- Don’t pair if there’s no need to. There are a lot of tasks that are better fulfilled when working on your own. These could be minor, routine, simple tasks. Don’t initiate a session for the sake of pairing.
- Don’t work all day in pairs. Our experience shows that for engineers who just started practicing pair programming, one session that takes 2-3 hours is more than enough for one day.
Artur Hebda
Full Stack Engineer
I don’t do more than 2 or 3 hour-long sessions a day, and these days are exhaustive. But I feel these days are nice because pair work forces you to be more focused the entire time.
At the end of a day, I feel that I achieved more than I would otherwise do, just on my own.
But having a single session longer than 3 hours a day, I guess would be too much for me.
Pair programming tools for remote teams
Railsware is a remote-friendly team with teammates in 13 different countries. Yet, we practice pair programming regularly and rely heavily on this practice during hiring, onboarding, learning, and knowledge sharing processes.
For pair programming sessions, our engineers have tried different tools and chose:
- Visual Studio Code with Live Share plugin – this combo allows developers to write code together by sharing parts of the code without sharing the whole repository access. We use it on our “full-day interview” with candidates who aren’t a part of our ecosystem.
- RubyMine with Code With Me plugin – is a standard choice of our engineers for a usual remote pair programming session.
For screen sharing, we mainly use:
- Slack call – as it’s 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 can also recommend you the Tuple app. Additionally, for coding work that does not require a browser open, it is handy to use ssh with tmux, especially when working at lower bandwidths.
Wrapping up
While some companies and engineers keep ignoring pair programming, being convinced it’s not worth the trouble, our team has the opposite opinion.
We practice pair programming to solve blockers on projects, validate great candidates, onboard newcomers, share expertise, and distribute knowledge within the team. Pair programming also helps Railswarians stay socially active and build strong interpersonal relationships while living in different countries.