Recently, I had the opportunity to experience what an enjoyable pair-programming experience is like, so, with the idea of experimenting with it at my current client, I’ve read a few articles on it (basically Martin Fowler’s introduction).

Pair programming was always a practice during which I either felt as a baggage, dragging down the other person, or as if I were going too fast and making the other person feel how I felt. (Yes, I know, a lot of projecting there.)

And then during after a workshop at PulpoCon25 with a lot of pair programming, a remark by the facilitators stuck with me, “Don’t hesitate to do a small retro on how you’ve both felt during the experience”.

I’ve actually never thought about asking the other person how they were feeling about the activity, about how they wanted to approach the pair session.

And now, onto the guide.

Pair programming — simplified

(Lots of what you’ll read here will be heavily inspired by the article above, it’s simply a means to understanding and simplification. For an in depth introduction, don’t hesitate to read it directly. I’ve basically picked and stripped what I felt was important for my current situation.)

Pair programming essentially means that two people write code together, it is a collaborative way of approaching problems and involves a lot of communication.

There are two roles in a pairing session, that should rotate between each of the participants.

The Driver is the person at the wheel, i.e. the keyboard. They are focussed on completing the tiny goal at hand, ignoring larger issues for the moment. A driver should always talk through what they are doing while doing it.

The Navigator is in the observer position, while the driver is typing. They review the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.

Pair programming styles

Driver and Navigator

Driver and Navigator style Image source: Martin Fowler’s article on pair programming

I think you can imagine how this one is going to go.

A common flow of this style goes like this:

  • Start with a reasonably well-defined task. Agree on one tiny goal at a time. This can be defined by a unit test, or by a commit message, or written on a sticky note.
  • Switch keyboard and roles regularly. Shared active participation keeps the energy level up, and we learn and understand things better.

As navigator, avoid the “tactical” mode of thinking, leave the details of the coding to the driver — your job is to take a step back and complement your pair’s more tactical mode with medium-term thinking.

Park next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done, so as not to interrupt the driver’s flow.

Ping-Pong

Ping pong pairing Image source: Martin Fowler’s article on pair programming

This technique embraces Test-Driven Development (TDD) and is perfect when you have a clearly defined task that can be implemented in a test-driven way.

  • “Ping”: Developer A writes a failing test
  • “Pong”: Developer B writes the implementation to make it pass. Developer B then starts the next “Ping”, i.e. the next failing test.
  • Each “Pong” can also be followed by refactoring the code together, before you move on to the next failing test.

(I’ve purposely left out the Strong-Style technique, as is something I don’t really understand how to introduce, or if it should be called pairing at all, in my opinion it looks more like a mentoring session.)

Pair development

Sometimes defined as another style of pair programming but, in my opinion, should be defined as the set of conditions and questions that complete and guarantee a successful outcome of a session.

They should be a pre-requisite for more exploratory or refactoring tasks, where the end-goal is clear, but the steps are yet to be defined. Good for domain discussions and defining research paths, before development can be started.

It basically should consist of three steps :

  1. Understand the problem Share context with each other if both of you are not up to the same level of information. Create diagrams, annotate classes and complete the tickets. (All of this can be useful for the post-development documentation of the task)
  2. Come up with a solution Brainstorm solutions to the idea, if one of the participants already has a solution in mind, let the other person some time to explore and propose something from their side. You can do this in a miro board, or a simple markdown file.
  3. Plan your approach: For the solution you chose, what are the steps you need to take to get there? Is there a specific order of tasks to keep in mind? How will you test this? Ideally, write these steps down, in a shared document or on sticky notes.

Research and explore

When implementing a feature or adding something to a feature neither of you are familiar with, you’ll need to do some research and exploration first.

Here is one way to approach this in pair development mode:

  • Define a list of questions that you must answer in order to come up with a suitable solution. e.g Frontend impacts, contracts of external services, auth requirements, deadlines, feature flip integration,…
  • Split up — either divide the questions among you, or try to find answers for the same questions separately.
  • Get back together after a previously agreed upon timebox and discuss and share what you have found.

Tips for a healthy pairing session

Just a few maybe dos and don’ts for your pairing sessions :

  • Time management — At the start of the session, define for how long are you going to be working together and at which intervals you want to take breaks. Consider using things like the pomodoro technique or other variations to enforce the breaks.
  • Plan the day — go into the session with a task in mind, and prepare a plan of action from the start
  • Remote pairing — setup tools like Visual Studio “Live share” exception or equivalents for your IDE, ensure you have a stable connection. There will always be lag, so don’t hesitate to switch the “main” machine from time to time so that is not only of you who deals with it.

Also as important is to define how each of you would like the session to go.

A conversation at the beginning of your pairing session can help you to understand differences between your styles, and plan to adapt to that.

Start your first session with questions like “How do we want to work together?”, “How do you prefer to pair?”.

At the end of a day of pairing, do a round of feedback for each other, you can think about it more as a mini retrospective. Reflect on how you both felt during the pairing session.

  • Were you alert?
  • Were you tired?
  • What made you feel comfortable, what not?
  • Did you switch the keyboard often enough?
  • Did you achieve your goals?
  • Is there anything you would like to try next time?

Things to avoid

  • Drifting apart, if you find yourself drifting to other subjects, we all have mails or teams to answer urgently from time to time, don’t hesitate to ask for a break instead of switching to other things. Be more aware of this when you’re in the “Navigator” position.
  • Micromanagement mode I don’t think it needs much explanation, it merges a bit with the next point. Apply the “5 seconds rule”: When the navigator sees the driver do something “wrong” and wants to comment, wait at least 5 seconds before you say something — the driver might already have it in mind, then you are needlessly interrupting their flow.

Pairing template

Pair Programming Session Planning Template

Pre-Session Setup

Date & Time: ______________ Participants: ______________ (Driver first) & ________________ (Navigator first) Duration: ______________ (total time) Break intervals: Every ______________ minutes Task/Goal: _________________

Session Approach

What style will we use?

  • Driver and Navigator (classic style with regular role switching)
  • Ping-Pong (TDD-based, alternating test writing and implementation)
  • Pair Development (exploratory work requiring upfront planning)

Role rotation frequency: Every _______________ minutes/after each _______________

Understanding Each Other’s Preferences

Take a few minutes at the beginning to discuss these questions together:

Working Style Questions

  • How do you prefer to pair? What has worked well for you in the past?
  • How should we handle interruptions or urgent messages during our session?
  • What’s your preferred way to suggest changes — immediate or after a natural pause?
  • How comfortable are you with the codebase/technology we’ll be working with today?

For Pair Development Sessions (if applicable)

Phase 1: Problem Understanding

  • Context shared between both participants
  • Problem clearly defined and documented
  • Key questions to answer: _______________

Phase 2: Solution Design

  • Both participants have proposed potential solutions
  • Chosen approach: _______________
  • Rationale documented

Phase 3: Implementation Planning

  • Steps broken down into small, achievable tasks
  • Order of tasks defined
  • Testing approach agreed upon

Research Tasks (if needed)

Questions to investigate:

Research approach:

  • Split questions between us
  • Research same questions independently
  • Timebox: _______________ minutes
  • Regroup time: _______________

Technical Setup (for remote pairing)

  • Screen sharing tool ready and tested
  • IDE collaboration tool set up (VS Code Live Share or equivalent)
  • Both participants can hear each other clearly
  • Agreement on who hosts the main development environment first

Session Ground Rules

Remember to maintain these healthy practices:

  • The driver always narrates what they’re doing while coding
  • The navigator parks ideas and obstacles on notes rather than interrupting flow
  • Apply the 5-second rule before suggesting corrections
  • Request breaks when needed instead of multitasking
  • Stay focused on the tiny goal at hand

End-of-Session Retrospective Questions

Reserve 5-10 minutes at the end to discuss:

Energy and Comfort

  • How alert did you feel during the session?
  • What made you feel comfortable? What didn’t?

Process Evaluation

  • Did we switch roles frequently enough?
  • Did we achieve our planned goals?
  • How well did we stick to our chosen pairing style?

Improvements for Next Time

  • What worked particularly well that we should keep doing?
  • What would you like to try differently next session?
  • Any adjustments needed to our pairing approach?

Notes Section

Obstacles encountered:

Ideas for future sessions:

Documentation needed:

Next steps:

This template is designed to facilitate productive pair programming sessions by establishing clear expectations and encouraging open communication between partners. Adapt as needed for your team’s specific context.