Pair & Mob Programming

Status: Complete
Category: Delivery
Default enforcement: Advisory
Author: PushBackLog team

Tags

• Topic: delivery, collaboration, quality
• Skillset: engineering
• Technology: generic
• Stage: execution

Summary

Pair programming is the practice of two engineers working at the same workstation — one writing code (the driver) while the other reviews, considers design, and navigates (the navigator). Mob programming extends this to the whole team (3–5+ people) around one screen or shared IDE. Both practices produce code that is reviewed as it is written, spread knowledge continuously, and prevent the “lone coder in a corner” dynamic that creates knowledge silos. Neither replaces code review or testing; they complement them.

Rationale

Reviews as you write, not after

In a traditional workflow, a developer writes code for hours or days and then submits it for review. The reviewer examines finished work, spots problems, and asks for changes — a slow feedback loop. Pairing makes code review continuous: the navigator is reviewing every line as it is written. Defects surface instantly rather than after a full implementation cycle, at the cheapest possible moment to fix them.

Knowledge transfer at the speed of working

Documentation describes finished systems. Pairing transfers knowledge about both the code and the reasoning behind decisions — including the wrong turns and the explored alternatives — at the speed of implementation. A senior engineer pairing with a junior engineer on a complex feature is worth dozens of documentation pages. The junior learns the codebase, the domain, and the design instincts simultaneously.

Mob programming for high-stakes decisions

When a decision affects the whole team (architecture choices, complex algorithms, the shape of a new API), having one engineer make it alone creates a risk: the rest of the team doesn’t understand it, can’t reason about it later, and can’t challenge incorrect assumptions. Mob programming externalises the reasoning. Everyone participates in the decision and understands it.

Guidance

Pair programming roles

Driver

• Controls the keyboard and mouse
• Writes code, executes commands
• Focuses on the immediate task: “make this test pass”

Navigator

• Does not type (unless instructed)
• Reviews code as it is written
• Thinks ahead: “this approach will cause a problem when we add X”
• Reviews the broader design: “should this live in this class?”
• Looks things up (documentation, Stack Overflow, codebase search) so the driver stays in flow

Switching roles

Switch roles regularly — every 25 minutes is a common pattern (Pomodoro-aligned). Both people must be able to drive. If the navigator never drives, they disengage.

A simple method: use a timer and switch at the sound of the alarm. The driver becomes the navigator; the navigator commits any in-progress work and takes the keyboard.

When to pair

Pairing adds the most value when:

• Tackling unfamiliar code, systems, or patterns
• Solving complex algorithmic problems
• Onboarding a new team member
• Working on security-critical or high-risk code
• The task requires decisions with significant downstream consequences

Pairing is less valuable for:

• Repetitive, well-understood mechanical tasks
• Research/spiking where one person needs to explore freely
• Tasks where thinking alone first produces better initial designs

Remote pairing tools

For remote pairing, ensure both participants have a reliable internet connection and use a tool with < 100ms latency. High latency makes the driver role frustrating.

Mob programming

Mob programming scales pairing to the whole team:

• One driver controls the keyboard
• One navigator gives directions
• Remaining mobbers observe, research, and contribute ideas
• Rotate often: typically every 5–10 minutes
• Everyone participates — no side conversations, no split attention

Mob programming is especially effective for:

• Complex features that the whole team will maintain
• Solving a hard bug affecting production
• Defining the shape of a significant new module or service
• Workshops and learning sessions

Psychological safety and pairing

Pairing works only in an environment where it is safe to make mistakes. If the driver feels judged for every typo or wrong turn, pairing becomes stressful rather than productive. Establish norms:

• Mistakes are learning opportunities, not failures
• The navigator does not grab the keyboard impatiently
• Both roles have equal standing — the driver is not implementing the navigator’s instructions; they are collaborating
• It is fine to say “let me think for a moment” before proceeding

Tracking pairing

Some teams use a pairing matrix to ensure cross-team knowledge spread — tracking who has paired with whom on which parts of the codebase over time. This surfaces silos and helps pairs rotate to maximise knowledge distribution.