Pair programming: roles, challenges, guiding principles, and tools

You’re staring at your code and thinking, “There’s nothing wrong here.” But there is: the app isn’t working. And you know the bug is staring you straight in the face. You finally turn to your colleague and begin explaining the problem, and suddenly, mid-phrase, it comes to you – the problem and the solution.

It seems, all you really had to do was…start talking??

If you’ve ever had this experience with software development (I have, many times), you know that talking out loud is important when solving problems. Either talking aloud with fellow programmers, or if working alone remotely, talking to a rubber duck (coined the rubber duck debugging method). Staring at code is also important, but not for too long.

So, get yourself a rubber duck, your colleagues say – seriously. Or better yet, get online and start pair programming together.

Pair programming has a history

In a thorough treatment on Pair Programming, authors Birgitta Böckeler and Nina Siessegger describe how:

Pair programming forces us to discuss approaches and solutions, instead of only thinking them through in our own head. Saying and explaining things out loud pushes us to reflect if we really have the right understanding, or if we really have a good solution.

They quote Jean Bartik, one of the original programmers for the ENIAC computer in the 1950s, who said:

Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each other’s errors, and use the best ideas.

So we knew it then and we know it now: pairing two or more software developers together to solve a single problem, in front of a single screen, creates great software.

While not necessarily extreme programming or agile software development, pair programming can be used to allow team members to build and architect software and learn to trust each other.

The driver/navigator model of pair programming (“You drive, I navigate”)

Pair programming involves two programmers sharing a single computer and keyboard. This can be done online with screen sharing or tools built for pair programmers (see below).

The classic metaphor in pair programming is the driver and navigator. The driver is at the wheel, the navigator looks at the map; the driver types, the navigator describes the problem and solution.

1. The process and benefits of pair programming

They both work equally hard. For example:

  • As the driver is writing code and thinking, the navigator talks, analyses, tests – all the while looking over the driver’s shoulder.
  • The driver’s role is to structure the code, decide on the variable names, write the loops, function, and condition that implement whatever the navigator is saying.
  • The navigator’s role is to shape the big-picture solution, frames the results, sets the constraints, does some code reviews.
  • The driver writes clean code. The navigator simplifies the problem.
  • Both driver and navigator design the architecture, decide on the database, technology, and the overall look and feel of the application.
  • Both driver and navigator are responsible for the final result, meeting the requirements of the original specs.
  • Driver and navigator celebrate together when they reach their destination.

2. Challenges and pitfalls

Conflictual moments go to the heart of why we pair up. For example:

  • What is the difference between describing a “solution” and coding an “algorithm”? For example, the navigator says to put a red circle in the middle of a screen, at real-time speed. To do this, the navigator says to code an asynchronous program. The driver disagrees, there’s no need for risky and complex asynchronous algorithms. There’s a better solution. So, who wins?
  • What happens when the navigator doesn’t like the code?
  • What happens when the driver doesn’t like the navigator’s ideas or analysis?

There are always two options to solve these conflicts: either the pair stays in their roles (and trust each other) or they break out of their roles and humbly discuss the options.

That’s the whole point: pair programming is about communication and teamwork, where two experts patiently teach each other to be better at what they do.

That’s also why it’s good to switch roles, to have the navigator take the wheel and follow the guidance of the driver-now-turned-navigator.

3. Mentoring or sharing expertise

There are often two pairing scenarios in pair programming:

  • senior-with-senior developer
  • senior-with-junior developer

Often, the latter scenario can make better use of a mentor-mentee situation, where the navigator not only establishes the big picture, but also might take over the typing to model for, teach, and share knowledge with the less experienced developer. We all can always become better drivers, yet this senior-with-junior pairing enables a clearer mentor-mentee situation.

When two seniors are paired together, the responsibilities of each role may need to be further discussed and defined as they set out on their voyage.

Start with values

We’ve discovered that pair programming works. On many levels: software engineering and softer aspects like teamwork and building up individual values.

In all scenarios, there are values at play: trust, candor, care, grit, and humbleness. Essentially, open communication reigns.

  • Candor
    • Learn to give feedback
  • Humility
    • Learn to receive feedback
    • Ask questions when blocked
    • Don’t be afraid of being wrong
  • Trust
    • Believe in your partner
    • Recognize and accept that others solve problems differently
  • Grit
    • Challenge each other
    • Motivate each other
  • Care
    • Foster teamwork
    • Make great products

Tools (software) for remote pair programming

Before finishing, it’s worth mentioning that all of this can be done remotely. Video conferencing with Zoom, Teams, Skype, and other such remote tools support screen sharing and even remote desktop control functionalities.

However, for more robust pairing features, you’ll want to use one of the tools that were built for remote pair programming like those listed below.

Here are some remote pair programming tool recommendations to assist you in your journey:

About the authorPeter Villani

Peter Villani

Sr. Tech & Business Writer

Recommended Articles

Powered by Algolia AI Recommendations

Good API Documentation Is Not About Choosing the Right Tool

Good API Documentation Is Not About Choosing the Right Tool

Maxime Locqueville

Maxime Locqueville

DX Engineering Manager
Algolia's top 10 tips to achieve highly relevant search results

Algolia's top 10 tips to achieve highly relevant search results

Julien Lemoine

Julien Lemoine

Co-founder & former CTO at Algolia
Building a composable front-end search with autocomplete and instant search results

Building a composable front-end search with autocomplete and instant search results

John Stewart

John Stewart

VP Corporate Marketing