Not a fan of pair programming? You’re not the only one.

For years, I hated pair programming. I thought it was an inconvenience without benefit, something you do to appease your manager or check a box.

I was wrong.

Over the last year, my co-founder and I have pair programmed for roughly 6 days a week. With practice, we’ve honed our setup and, in doing so, figured out an effective way to collaborate on code.

In this post, I will share our pair programming formula and outline the benefits that we enjoy. I will also discuss the challenges and downsides of pair programming to prepare you for any pushback that you might receive.

If you’re new to pair programming, I hope this post inspires you to apply it in your daily life.

If you’re not a fan of pair programming, I hope this post challenges you to reframe your past experiences and rethink collaborative coding.

Either way, I provide an actionable plan to help you implement and optimize a collaborative setup.

Let me be clear: pair programming doesn’t work for every project or for every team. But, it works for us and it might work for you. This post is for developers who are open to trying something new.

What follows is a deep dive into pair programming. Feel free to skip ahead to the sections that interest you the most:

• What is pair programming?
• Optimizing your pair programming setup
• Benefits
• Challenges & downsides
• Pairing on other tasks
• Programming threesomes
• Conclusion

Let’s get into it.

What is pair programming?

Pair programming is a collaborative style of working on software development projects. It involves two individuals who are both engaged on the same code at the same time.

This is not the official Agile definition, which stipulates that developers share a single workstation.

To be clear: working side-by-side is not my ideal setup and I will not attempt to convince you to use it. Virtual pairing is far superior to brushing elbows – but, more on that later.

In a typical pair programming session, there are two different roles:

• The Driver – writes code
• The Navigator – offers direction and reviews code

Every so often, the Driver and the Navigator switch roles. How frequently this occurs depends on the team and the project – it can range from every few minutes to every few hours. The swap can also be triggered by an event, such as the Driver finishing a unit test or getting stuck.

The Driver and the Navigator maintain a running commentary throughout the duration of the session. This is often called “programming out loud” and it is a challenge in itself. Speaking while coding is like narrating your morning routine: you’re forced to vocalize something internal and often subconscious. Add in the fact that there’s another human listening to your rambling and it’s not surprising that developers struggle to program out loud.

Regardless, for non-developers, pair programming seems harmless. You’ve got two developers coding together in real time. What’s the big deal?

In reality, pair programming is a polarizing practice. Software developers are are either enthusiastic evangelists or outspoken opponents. Few claim to be ambivalent.

Until recently, I was a pair programming skeptic. My opinion had soured over the course of several years due to bad experiences falling into one of four categories:

1. Personal space violations: pairing with someone who has a greasy desk or unpleasant BO.
2. Misaligned objectives: pairing with someone who refuses to engage, or, even worse, is more interested in showing off than collaborating.
3. Management disasters: pairing with multiple people in a “group coding project” (a special type of hell that is inevitably doomed to failure).
4. Character clashes: pairing with a bullish extrovert for a series of memorably uncomfortable and counterproductive sessions.

For me, the net result of these negative experiences was a strong aversion to pair programming.

And that was pretty much the end of it. I avoided pair programming at all costs and off I went on my merry way.

Until I started pair programming with my co-founder.

Fast forward a year and now admit that I was wrong. It took finding the right partner and experimenting with different setups to finally unlock the benefits of pair programming.

In the next section, I outline the key components of an optimal pair programming setup. This includes finding a suitable partner, scheduling sensible time blocks and utilizing collaborative technologies.

Finally, I’ll discuss the practical logistics to help you structure your environment for remote pair programming success.

Optimizing your pair programming setup

My co-founder and I have pair programmed roughly 6 days per week since March 2020, with each session lasting between 1 and 5 hours.

Here are the essential elements that make up our hyper-productive pair programming sessions:

A Suitable Partner

Finding the right person to pair with is the foundation of any successful pair programming session. This is obvious.

What is not so obvious is what exactly constitutes the “right person”.

Personality

Personality plays a big part of any successful relationship. If you’re going to be pair programming with someone every day, it’s important to make sure that you both get along.

Current or former colleagues can be perfect partners because your professional relationship sets the tone for your future engagements. The challenge with colleagues is to assess whether your personalities are a match; make sure to do a trial run or two.

Friends can also make good partners, but you must be careful to avoid distraction. Your personal relationship may inhibit decision making and detract from the seriousness and focus of your sessions.

Rather than be overly prescriptive, I will outline the important qualities to look for in a pair programming partner:

• Humility and humor. Find someone who can admit to being wrong and laugh at their mistakes. Don’t let ego third wheel your pair programming sessions.

• Willingness to communicate. When working remotely, communication is key. My co-founder and I both make a concerted effort to be better listeners and let each other finish our thoughts. Interruption is even more jarring when you’re not sitting in the same room.

• Commitment. A mismatch in commitment will result in differing levels of interest and output. This will inevitably lead to resentment between contributors.

Experience & Skills

Should you pick a partner with the same expertise? In my experience, no – diversity trumps overlap.

For example, my co-founder is a software developer and data scientist. He has significantly more technical experience than I do and is much faster at translating ideas into code.

It sounds like we might be a poor match, but the opposite is true:

• Because I ask novice questions, my co-founder is challenged to understand and explain concepts more thoroughly.
• Because I am often unfamiliar with the language we’re using, I spot things that only a fresh pair of eyes would.
• Because I am slower to write code, we talk through solutions before implementing them, thus avoiding needless time sinks.

The big caveat is that my co-founder actually wants to work with me. We acknowledge and celebrate the differences in our skill sets, rather than resenting one another for not being on the same level.

The combination of my design expertise and his programming skills enable us to own the development pipeline. We can start with an idea and translate it from mockups through to a final deliverable. We can tackle a wide variety of tasks without relying on other parties, thus speeding up the process and maintaining control.

I cannot overstate: diversity in skills gives you super powers.

Finally, I understand that not every developer has the luxury of choosing their pair programming partner. In this case, you must lead by example and champion the important qualities outlined above. Your efforts will determine your success.

Recommendations

Find a partner with a different skill set. Don’t worry if there’s an experience gap, it’s often better that way. Discuss what each of you bring to the table and acknowledge your strengths and weaknesses. Practice being better listeners.

Schedule

Once you’ve found the right person, when and for how long should you schedule your pair programming sessions?

The time of day that you choose will be personal preference and job specific. We originally started coding in the mornings to get in a few hours before our 9-5 jobs. We’ve since stuck with this schedule and have found that a 7am start time works best for us.

At the beginning of every session, we confirm our stop time. Sessions are capped at five hours, which includes no more than four hours of active coding. To quote Cal Newport’s “Deep Work”, this time is dedicated to “distraction-free concentration that pushes [our] cognitive capabilities to their limit”.

But why not schedule longer sessions?

As we discovered early on, pair programming is physically and mentally exhausting. Working with a singular focus requires intense attention and intention. And, unlike solitary deep work, pair programming comes with an accountability partner who helps you stay fixated on the task at hand. You don’t have the luxury of context switching to something easier when what you’re working on gets tough.

We also block off all pair programming time in our calendars to prevent interruption.

During long sessions we usually take one or two five- to 10-minute breaks. We don’t schedule these rest periods, but instead take them whenever one of us needs to.

Breaks are a chance to stretch our legs, make a fresh coffee and come back to our desks feeling refreshed. As many software developers can attest, bugs are often squashed immediately upon returning from a break.

Finally, our sessions happen daily, unless otherwise agreed. This consistency helps us stay on top of outstanding tasks and promotes a mindset for collaboration.

Recommendations

Choose a time of day that works for your schedules and stick to it. Agree on a stop time and take thoughtful breaks. Effortful pair programming is both mentally and physically draining, so start short and work toward longer sessions.

Technology

A successful pair programming session requires a few key technologies.

First, you need to be able to communicate with your partner. For this, my co-founder and I use Slack.

Each session begins with morning greetings sent via Slack chat followed by a Slack audio call. Throughout the session, we also use Slack chat to send each other links and code snippets.

Most importantly, we do not turn on our video cameras. Not only is video distracting, but it invades upon the privacy and comfort of our personal environments.

Depending on what we’re working on, we will screenshare using Slack. This is particularly helpful when we are doing mobile development because it enables both of us to view the app simulator.

Next, we use VS Code for our code editor because it supports pair programming via an extension called Live Share. This extension generates share links that you can use to invite people to join your coding session.

Once your partner has joined your session, you can both write code in real time and see each other’s cursors. There is also a “follow” feature, which allows you to shadow someone and “see what they see” as they navigate around the project. This is invaluable for less experienced programmers who aren’t familiar with the structure of a codebase.

VS Code is not the only editor that supports collaborative coding. Another option is IntelliJ, which enables you to share your project with one or more guests using a feature called Code With Me. Code With Me has a more convenient “follow” feature but seems to be flakier when it comes to real time collaboration on the same file. The text editor Atom also offers a pair programming plugin called Floobits, which I have not yet tried.

Finally, if you are doing data science work, I recommend checking out Deepnote for in-browser Python notebooks that offer real-time collaboration.

Recommendations

Choose a technology stack that enables you to communicate and collaborate easily. Audio calls only, no video.

Logistics

As I mentioned at the start of this post, pair programming is traditionally an in-person activity. Developers sit side-by-side and share a single keyboard. In my opinion, this setup restricts technical output and invades personal space.

Instead, my co-founder and I work together, remotely. We enjoy the comfort of our own desks and familiarity of our own computers. When either of us wants to jump into the code, we don’t have to physically take over a shared keyboard.

However, for all of its downfalls, in-person pair programming does help developers stay focused. Your attention is less likely to wander if you are working with someone who is sitting right next to you. Therefore, it is important to set up your remote workstation to reduce distractions.

I try to abide by several key rules:

• Schedule – Blocked off.
• Phone – Removed from desk or placed face down with notifications turned off.
• Unnecessary tabs and applications – Closed.
• Door – Also closed.

By following these rules, you structure your pair programming environment to maximize the amount of time that you can focus on deep work.

Now, for the sessions themselves.

Every day, we take turns driving the session. The Driver opens applications locally, pulls down code, starts Live Share sessions, runs simulators and commits code to source control at the end of the session.

Swapping the roles of Driver and Navigator on a daily basis is beneficial because:

1. It ensures that everything works on both of our machines. Sometimes this means that instead of writing new code, we spend an extra hour on installations or setup. It seems like a pain but it’s worth it to know that we always have a working version of the code.
2. It promotes knowledge transfer and familiarity with the codebase. We both work on everything. This promotes a broad understanding of how systems fit together.
3. It is not overly disruptive. Frequent role switching, in my opinion, unnecessarily interrupts the flow of the session. By switching roles once per day, we enjoy all of the benefits while minimizing the time spent closing and re-opening applications and regenerating share links.

At the end of sessions, we create and review a pull request. This gives us the opportunity to walk through all of the changes that we have made and identify any outstanding issues. These code reviews tend to be very quick, since both of us are already familiar with the work.

Finally, we complete our sign-off ritual by reviewing our outstanding priorities and making a plan for the next day. This includes deciding on a start and end time and the specific tasks that we want to accomplish.

Recommendations

Avoid personal space violations by respecting your partner and prioritizing comfort. Create a distraction free workspace. Experiment with switching roles to find a frequency that works for you. Complete each session by reviewing your progress and priorities.

---

To summarize, there are a lot of different variables to account for when planning your pair programming sessions.

It takes time, effort and a bit of luck to find the right partner. Likewise, it takes time and effort to hone your schedule, select your technology stack and optimize the logistics of pair programming.

Is all of this time and effort worth it? I think so.

Let’s now look at the main benefits of pair programming.

Benefits

First, and perhaps most obvious, pair programming results in higher quality code and a short feedback loop. This is because the collaborative process is almost like an extended code review. The two developers assess every decision and can fix problems before they enter source control.

Less obvious is the benefit of slowing down, an inescapable part of pair programming. As you’re working in tandem with your partner, it is both natural and desirable to spend a significant amount of time in conversation. This “wasted time” often forms part of the argument against collaborative coding. In reality, the slower pace typically results in productivity benefits. How can this be?

While constant communication means fewer functions per minute, it also means better articulation of the problem. This improves focus and reduces the time spent ping ponging between various dead ends. Thus, “programming out loud” is a counterintuitive way to boost to your development speed.

Pair programming also has notable benefits when a more experienced developer works with a less experienced developer. In this case, the senior dev improves his or her understanding and ability to express ideas in a clear and succinct way. Meanwhile, the junior dev is able to expand his or her abilities and build confidence.

On a higher level, pair programming is great for the team and the mission. It fosters cohesion, knowledge transfer and alignment between developers. It also promotes a holistic, rather than siloed, understanding to keep everyone in the loop about the codebase as it grows over time.

Finally, on a practical note, pair programming boosts developers’ capacity for prolonged deep work. Well-matched partners hold each other accountable to stay singularly focused on cognitively demanding tasks. Alone, you might succumb to distraction or the mental release of easier work. Partnering with another developer who expects you to be fully present cultivates intense focus.

As my co-founder and I have experienced, the productivity benefits are simply amazing.

Now, before you come at me with a pitchfork, let me be the first to admit that there are challenges and downsides. Let’s look at some of the drawbacks involved with pair programming.

Challenges & downsides

The main challenges associated with pair programming result from misaligned developers.

On the one hand, clashes in personalities or communication styles can lead to resentment or lopsided output. On the other hand, too friendly a relationship can be distracting and hinder attempts to produce quality work.

Collaborative coding is also demanding. Developers need to be patient and conscientious. They must be accepting of differences in experience levels and backgrounds. They must be comfortable not knowing everything.

Pair programming efforts will implode if either developer does not want to collaborate. The practice does not align with “rock star” hacker or “lone wolf” mentalities.

Similarly, pair programming requires a lot of trust. Both partners need to be committed to the project and willing to engage for hours at a time.

Developers must agree on a schedule and commit to showing up mentally and physically. Done well, pair programming hacks your deep work threshold and enables you to focus on hard tasks for long periods of time. Pushed too far, it can result in burnout. To strike the right balance, partners must be willing to experiment with different schedules and time blocking.

Pre-COVID, pair programming sessions meant shared workstations. This was an instant turn off to many developers (including myself). COVID has ushered in a new acceptance of remote working, however, there is still pushback. Explain to a business user that two developers are being deployed when one would suffice and you’re sure to raise eyebrows. The reality is that pair programming remains an unconventional practice. It requires unconventional trust and flexibility on the part of the company and the team.

Unfortunately, there is no shortcut to changing people’s misconceptions. Business users will always criticize wasted resource and “rock star” developers will always complain that they can do better by themselves.

However, I hope that this blog post will help increase awareness and promote the benefits of pair programming. I want you, dear reader, to lead the way for your team to adopt collaborative practices in the future.

On that note, you might be wondering if pair programming can be extended to tasks outside of writing code. Let’s take a look at that next.

Pairing on other tasks

For my co-founder and I, there are no activities that fall strictly outside of the scope of our pair programming sessions. However, some tasks are better suited for independent effort.

Technical Research

If we get stuck on a technical problem, my co-founder often investigates the issue after our normal pair programming sessions. This involves reading articles and Stack Overflow posts as well as experimenting with various potential solutions. In these instances, reading independently is the fastest way for my co-founder to get up to speed.

Afterwards, we perform an abbreviated code review and discuss the ultimate solution. The goal here is not to equalize our levels of understanding. Instead, we favor shared awareness and continued forward momentum.

Design

Just as my co-founder leads on technology, I lead on design.

For me, design is an independent pursuit: I prefer to create and iterate on mockups, prototypes and graphics on my own.

However, once I am ready for feedback, I like to perform live revisions in Figma during a pairing session. Figma is a free in-browser interface design tool that promotes collaboration and rapid iteration. It is an awesome way to include developers in the design process.

Writing

No surprise here: my co-founder and I write blog posts and other long-form content independently.

But, if we need to compose startup related material or write application responses, we prefer to do so together. Our favorite tools include Google Docs and Notion.

Collaborative writing begins by pasting any prompts or questions into a shared document. Then, both of us begin writing. The goal is to get as much written down as possible, as fast as possible – for this, four hands is definitely better than two.

After writing for a while, one of us will read aloud what we have written. Having a second pair of eyes and ears accelerates how quickly we converge on high quality content. It also almost always prevents writer’s block.

If you’re not sold on the idea of collaborative writing – I don’t blame you. It can be hard to string together the right words even without someone else tapping away in the same document. If that’s you, no worries! But you won’t know for sure until you give it a try. 😉

Programming threesomes

Does pair programming work with more than two people? Anecdotally, I’ve contributed to two successful programming threesomes.

I’ve also seen programming threesomes fail miserably. These situations are examples of “too many cooks in the kitchen”. Often, if one person drives and one person navigates, the third person is left to twiddle their thumbs.

If you are interested in exploring a trio setup, here are two ideas for how to make it work. In both scenarios, three participants communicate via an audio call and collaborate using VS Code Live Share or IntelliJ Code With Me (see Optimizing your pair programming setup).

Programming threesome – setup 1

• Driver: less experienced developer
• Navigator: experienced developer
• Researcher: experienced developer

In this setup, two experienced developers take turns being Navigator and Researcher. Another developer plays the role of Driver.

Throughout the session, the Navigator is in constant communication with the Researcher. They discuss and decide upon implementation details, referring to online resources as needed. Meanwhile, the Driver implements instructions from the Navigator and benefits from knowledge transfer.

This particular setup works well on difficult programming tasks. In these situations, an additional experienced developer supplements the pair’s combined knowledge. In this way, the trio is able to produce higher quality output.

Programming threesome – setup 2

• Driver: developer
• Navigator: developer
• Business User: non-technical business user

In this setup, the Business User possesses specific non-technical expertise that is fundamental to the project. The Business User discusses specifications with the Navigator who translates business knowledge into programmatic solutions. Finally, the Navigator provides navigational directions to the Driver.

This particular setup is inspired by a unique software development project that I worked on in 2020. This project was driven by the input and participation of an unusually engaged business user. One of these days I’ll write an entire blog post on the topic of end user buy-in. For now, suffice it to say that beautiful, powerful things can happen when business and technology meet.

Conclusion

In this post, I have outlined the key considerations for successful pair programming. I hope that it gives you a starting point upon which to structure and optimize your own collaborative setup.

Admittedly, it’s easy to get pair programming wrong. Force developers to sit side-by-side and you’ll cultivate resentment not innovation. Mismatch personalities or communication styles and you’ll get backlash not engagement.

But, done well, pair programming is like magic. It produces higher quality code, improved knowledge transfer and alignment between teammates. It also boosts developers’ capacity for deep work. And who doesn’t want to improve their ability to tackle cognitively demanding tasks?

Many developers dismiss pair programming after one or two bad experiences. And if you’re a skeptic – trust me, I get it.

Luckily, I decided to give it another shot. Together, my co-founder and I have enjoyed the benefits of pair programming for almost a year.

In the end, collaboration might not work for you. But, I hope that this post challenges your assumptions and inspires you to rethink pair programming.

---

Thanks for reading. I’d love to hear about your experiences with pair programming – please tweet me @amypeniston. Cheers.