Double the Brains, Double the Power!

They say two heads are better than one, and it’s often especially true when it comes to coding.

I can’t tell you the number of times I’ve been stuck on a coding issue and have had to ask for help. This has often meant jumping on a video call with a fellow developer and sharing my screen so we can tackle the problem together.

It’s a situation I’m sure every developer has been through at some point or another, and it helps massively during the learning journey.

What is Pair Programming?

Sometimes there’s more to offer than just giving someone a helping hand when they’re stuck or vice versa.

Sometimes as developers, we plan to work on a task together from the start, in the hopes that we can reduce the amount of blockers with two pairs of eyes and two brains.

All of this is known in the industry as Pair Programming.

Pair Programming is a technique that originates from Agile methodologies, particularly Extreme Programming, where two developers work together on the same code at a single workstation (this has evolved over time with remote working, but more on that later).

Kent Beck, the original creator of Extreme Programming says this about the aim of pair programming:

“Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team's practices.”

Whether you’re already working as part of a software engineering team or you’re just getting started learning how to code, pair programming will no doubt be a part of your journey.

So the more you know about it the better!

In this article, I want to give you the Ultimate Guide to Effective Pair Programming, including techniques and strategies for success, as well as habits to avoid, and the tools that can help with pairing sessions.

Now take my hand, and let’s take a look…

The Flow of Pair Programming

In software engineering teams, the flow of pair programming starts with the concept of Collective Code Ownership. This is where everyone in the team is encouraged to contribute new ideas to all aspects of the project.

The idea is that “any developer can change any line of code to add functionality, fix bugs, improve designs or refactor”, which means no individual becomes a barrier or blocker for changes and progress.

This is where pair programming is best used, as because no one is in charge of a single aspect, team members can freely work together and create a “flow” or loop of continuous integration.

This is how it looks in practice:

Benefits and Setbacks of Pair Programming

As you can imagine there are several benefits to doing pair programming.

Here are some key ones:

1. Improved code quality
It enables real-time code review and feedback, allowing for early detection of issues, better consistency to coding standards, and higher-quality code overall.

2. Efficient communication
It encourages constant communication between developers, leading to faster problem-solving, effective coordination, and a shared understanding of project goals and requirements.

3. Fewer errors and debugging time
With two developers actively involved in writing code, pair programming helps catch errors and bugs early, reducing the time spent on debugging and minimising the chances of releasing faulty software.

4. More knowledge sharing
By working collaboratively, pair programming promotes the exchange of ideas, techniques, and expertise, allowing developers to learn from each other and improve their skills collectively.

5. Better job satisfaction
It can help make work more enjoyable, as well as promote teamwork, and provide opportunities for continuous learning and growth. This leads to increased job satisfaction among developers as you’ll feel more engaged and supported in your work.

However, it may not be all fun and sunshine, there are some setbacks and disadvantages that can also come with pair programming, such as:

1. Reduced productivity
Pair programming can sometimes result in slower progress as two developers are working on the same task simultaneously, leading to a potential decrease in overall productivity.

2. Clash of personalities
Conflicting work styles, communication preferences, or personal differences between developers may lead to tension or disagreements that hinder effective collaboration.

3. Increased fatigue
Working in pairs for extended periods can be mentally and physically exhausting, potentially resulting in fatigue and reduced concentration, which may impact the quality of work produced.

4. Unequal work contributions
There is a possibility of one developer dominating the pairing session, leading to an imbalance in work contributions, where one person is more engaged in the coding while the other takes a passive role, resulting in an uneven distribution of effort.

5. Higher costs for companies
Pair programming requires two developers to work together, which can increase costs for companies, as they need to allocate resources accordingly, potentially reducing the number of tasks that can be worked on simultaneously.

Whilst some of these benefits and setbacks are specifically related to working as a developer within a company, many of them still apply to pairing in general so useful to know even if you’re still learning.

Pair Programming Techniques

With the benefits and setbacks in mind, let’s look at some pair programming techniques.

So you’ve got your pairing buddy and you’re ready to code, now what do you do next?

Depending on your set up you’re probably unlikely to be able to code at the same time, therefore there are several ways to cooperate:

Unstructured 🔀

An informal approach where two programmers collaborate without specific roles or guidelines, freely sharing the workload and responsibilities while continuously communicating and collaborating.

This type of pair programming is commonly used when no specific approach is being used.

With the freedom of no structure, it can often make a coding session move faster.

Best for: All levels of developers where each person can take turns as they see fit / are comfortable with.

Driver/Navigator 🚗

Think of a time when you might have taken a car trip to somewhere unfamiliar.

If you were the driver you’d be focused on the actual activity and mechanics of driving to the destination. Whereas if you were the passenger, you might be guiding the driver and thinking of the bigger picture for mapping out and helping get to that final destination.

This is pretty much how this technique works with pair programming.

Arguably the most popular type of pairing, one person takes on the role of the "driver" actively writing the code, while the other person acts as the "navigator," providing guidance, reviewing the code, and suggesting improvements.

Roles can be frequently switched to maintain a fresh perspective.

Best for: Two experienced developers who can easily trade roles. Or also one experienced developer with one novice, where the experienced dev may mostly navigate to encourage the novice to code and avoid them sitting passively.

Backseat Driver 👀

Similar to the driver/navigator approach, the backseat driver technique involves one person actively coding (the driver), while the other person provides guidance and feedback (the backseat driver).

However, the backseat driver has more involvement such as giving more tactile instructions and providing suggestions even before the code is written.

For example, this could mean telling the driver when to write a new method or open a new file. Or telling them what to name a variable or a test.

Best for: Works best with one novice and one experienced developer where the novice is the driver. That way it gives the novice a chance to learn by doing things in the way the experienced dev would.

Tour Guide 🗺

Remember the last time you went on a tour? What happened?

Most likely the Tour Guide or Driver took you through the place of interest and told you information about everything you were seeing and everything they were doing.

That’s basically what happens with this technique.

One person acts as the "tour guide" and walks the other person through the codebase or a specific section, explaining the architecture, design patterns, and implementation details.

The goal is to transfer knowledge and provide a comprehensive understanding of the codebase.

Best for: Works best with one novice and one experienced developer, particularly if the novice is a newbie. But also good to flip the roles and allow the novice to give it a go for a while whilst the experienced dev observes. That way the experienced dev can provide feedback and correction to the novice to help them learn.

Ping-Pong 🏓

This technique is very closely aligned with Extreme Programming, with the practice of Test-Driven Development or TDD.

It involves developers taking turns writing code and writing tests for the code.

One person writes a failing test, and then the other person writes the code to make the test pass.

They switch roles and continue this iterative process, emphasising test-driven development and collaboration.

Repeating back and forth - just like a game of Ping-pong!

Best for: All levels of developers, especially between two experienced devs. But also between two novices with the goal of allowing them to practice and encourage one another.

Mobbing 👨‍👩‍👧‍👦

No this has nothing to do with the Mafia.

Mob programming involves the entire team or group of developers working together as a "mob" on a single task or problem.

All team members actively contribute, with one person typing on the keyboard at a time while others provide input, guidance, and review.

Mobbing promotes collective ownership, knowledge sharing, and continuous collaboration throughout the development process.

Any of the pair programming techniques above can be used within the mobbing session

Best for: All levels of developers, useful for knowledge sharing and tackling really complex problems.

Pairing Habits to Avoid

Now that you’re familiar with all the techniques for pair programming, it’s important to look at some of the habits to avoid in order to have the best pairing experience.

We may be developers but we’re human first, and different bad habits can creep in whether we are in the driver or navigator seat.

So try to nip these in the bud:

For Drivers 🚕

• Driving too fast - Avoid moving at a pace that leaves your navigator struggling to keep up. Dictate your actions and ensure your pair is following along.

• Allowing navigator to “check out” - If you sense that your navigator is losing focus or not fully understanding what you're doing, pause and sync up. Maintain constant two-way communication to ensure active engagement from both parties.

• Not taking breaks - Pairing can be mentally draining, so it's crucial to take regular breaks. Consider using the Pomodoro Technique or agreeing on work and break intervals with your pair beforehand to ensure sufficient rest and recuperation.

• Listening without hearing - It's challenging to listen attentively while typing. When your navigator makes a suggestion or provides input, consider taking your hands off the keyboard. Even better, turn towards them, make eye contact, and give your full attention to the conversation.

• Unequal screen access - Position yourselves so that the monitor is between both of you, allowing equal visibility. Or if pairing remotely ensure the other person can see what you’re doing properly by zooming or enlarging the code on the screen.

For Navigators 🧭

• Jumping on errors too quickly - Allow the driver to notice and correct their own syntax errors and typos. Constantly pointing out minor mistakes can disrupt the flow and make your pair self-conscious. Focus on the bigger picture rather than immediately pointing out small errors.

• Giving low-level instructions - When providing suggestions to the driver, communicate in a simple way that they can understand. Avoid dictating code or individual keystrokes. Instead, try to convey your ideas at a higher level of abstraction. If necessary, ask to take the wheel temporarily to sketch out your idea.

• Not providing any input at all - If you’re a navigator avoid just sitting back and not saying anything. Remember the goal here is to work together so communication is key. Even if you’re a novice and don’t know what to say, ask questions instead, if the driver is doing something you don’t understand, ask them to explain it.

For Everyone 🔍

• Allowing unproductive distractions - Before starting a pairing session, eliminate all potential distractions by disabling notifications on your computer and phone. Minimise interruptions from phone calls, text messages, and emails to maintain focus and productivity.

• Not swapping roles - Remember to regularly switch roles between driving and navigating. Each role requires different mental effort and resting the tired parts of your brain while activating the idle ones. Use a timer as a reminder to switch roles to help keep the pairing session dynamic and energised.

• Forgetting it's a skill - Recognise that pair programming is a skill that improves with practice. Don't get discouraged if you struggle initially or assume that experienced developers are automatically good pairing partners. Reflect on each session, seek feedback, and continue practising to enhance your pair programming abilities.

Pairing Tools

I mentioned at the start that traditionally pair programming was a method that was done in person with two developers sitting together and sharing a computer or workspace.

However, times have moved on, and with the increase in working from home, many developers have been pairing up remotely instead.

To effectively do pair programming remotely, you’ll need to have the right tools for the job where you can easily share your screens with one another as well as communicate.

Here a are few tools that can help with this:

1. Code With Me
A service by JetBrains that enables real-time collaborative coding and pair programming by allowing you to invite others to work on your IDE project simultaneously.

2. Visual Studio Live Share
A versatile tool that allows real-time collaboration for coding, debugging, and reviewing, enabling you to share your project with peers without needing to clone a repo or set up an environment, all while maintaining your existing workflow and offering customisation options.

3. CoScreen
A video collaboration tool designed for technical teams, enabling pair programming and incident resolution through multi-user screen sharing, specifically tailored for distributed engineering and DevOps teams.

4. Tuple
A purpose-built, high-fidelity remote pair programming tool. It offers features like multi-user control, low CPU usage, 5K-quality video streaming, and a clutter-free interface, designed specifically to enhance the interactive process of remote pairing for developers.

5. Screen Sharing through Video Calls
As not all of the above tools allow video/audio communication you may also need to pair them with tools that offer screen-sharing capabilities such as Zoom, Slack, Microsoft Teams or Google Meet to name but a few.

Even without the coding tools above, as long as you can share your screen so the other person can see the code, that’s all you need to get started with pair programming remotely.

Conclusion

To conclude, pair programming, as we've established, is a useful technique for collaboration, enhancing productivity, knowledge sharing, and code quality.

From understanding the flow of pair programming to exploring various techniques and strategies, we've explored the heart of this collaborative coding approach.

Remember that the ultimate goal of pair programming, like any other development methodology, is to improve the quality of your software and the productivity of yourself or your team.

It's about creating an environment that encourages learning, sharing, and growing together.

Regardless of if you’re an experienced developer or just starting your coding journey, if you can practise pair programming effectively you’ll be sure to have an enjoyable coding experience.

Coding is fun, and two can play that game!

From your fellow ever-growing dev,

Cherlock Code

💙 If you liked this article...

I publish a weekly newsletter to a community of ever-growing developers, seeking to improve programming skills and stay on a journey of continuous self-improvement. Focusing on tips for powering up your programming productivity 🚀.

Get more articles like this straight to your inbox.

Let’s grow together 🌱

And stay in touch on 🐦 @evergrowingdev