Pair Programming

What it is

Pair Programming is an Extreme Programming (XP) practice where two developers share a single workstation — one keyboard, one screen, one problem. The Driver writes the code, focusing on syntax and immediate implementation. The Navigator reviews each line, thinks about strategy, spots errors, and considers the bigger picture. Roles swap every 15–30 minutes to keep both minds engaged and prevent fatigue.

The practice improves code quality through continuous, real-time review. Bugs are caught as they are typed rather than days later in a pull request. Knowledge spreads organically: when two people write every line together, there is no single point of failure. This directly reduces the bus factor — the number of people who could disappear before critical knowledge is lost.

When to use it

• Complex features: When the solution is not obvious, two brains reduce the risk of architectural missteps.
• Critical bugs: Production incidents benefit from paired investigation to avoid hasty fixes that create new problems.
• Knowledge transfer: Pairing is the most effective way to transfer deep system knowledge between team members.
• Onboarding: New hires ramp up faster when embedded in a pair from day one, learning conventions and tooling through doing.

Key concepts

Driver vs Navigator

The Driver handles the mechanical work: typing, navigating files, running tests. The Navigator thinks ahead, asks questions, and catches mistakes. A healthy pair talks constantly. When conversation stops, the quality benefit stops too.

Pair Rotation

Rotating pairs daily or every few days spreads knowledge across the team. Instead of two specialists who only know one area, you build a team where most members can work on most parts of the codebase.

Strong-Style Pairing

In strong-style pairing, the Navigator dictates what to type and the Driver translates into code. This prevents the more senior person from grabbing the keyboard and bulldozing the session. It is especially useful for mentoring.

Remote Pairing

Remote pairs use screen sharing, VS Code Live Share, or Tuple to replicate the single-workstation experience. Good audio is essential; video helps but is secondary. Both participants need push access to the branch and should swap control frequently.

Common pitfalls

• One person dominating. If the senior developer types while the junior watches, it is not pairing — it is a lecture. Use strong-style pairing or enforce role swaps.
• Pairing for trivial tasks. Updating a config file or renaming a single variable does not need two people. Respect the practice by saving it for meaningful work.
• Not swapping roles. The same person driving for two hours creates fatigue and unequal ownership. Set a timer.
• Using pairing as an excuse to avoid docs. Pairing spreads knowledge, but it does not replace architecture decision records, API documentation, or runbooks.
• Forcing pairing in an unsupportive culture. If management measures individual output (lines of code, tickets closed), pairing will feel like career suicide. Fix the metrics before pushing the practice.

NZ context

New Zealand has a smaller tech talent pool than larger markets, which makes retaining specialist knowledge especially important. When a senior developer leaves an Auckland or Wellington team, their expertise often walks out the door with them. Pair programming is one of the most effective ways to distribute that knowledge before it disappears.

Remote pairing via VS Code Live Share is common in distributed NZ teams spanning Auckland, Christchurch, and remote workers in regional centres. The practice works well across New Zealand’s internet infrastructure, though rural connections may require lower-bandwidth options such as screen sharing with audio-only.

Career level guidance