Pair Programming: Two Heads, One Keyboard

The mental model

Pair programming is a continuous, real-time code review. Instead of one person writing code and another reviewing it hours or days later, two developers tackle the problem simultaneously. One person is the tactical 'Driver' at the keyboard, while the other is the strategic 'Navigator' who reviews, questions, and plans ahead.

How it works

Two programmers work together at a single workstation. They take on distinct roles that they switch frequently, often every 25-30 minutes. The Driver is responsible for writing the code, focusing on the immediate task of translating thoughts into syntax. The Navigator observes the code as it's typed, looking for typos, logical errors, and opportunities for improvement. The Navigator also keeps the broader goal in mind, thinking about the next steps and overall design.

When to use it

This technique shines in specific situations. First, for complex or critical features where the cost of a bug is high; the second set of eyes catches errors early. Second, for onboarding new team members; a senior can navigate while a junior drives, accelerating knowledge transfer. Third, when a team is stuck on a difficult problem; pairing can break through creative blocks.

When not to use it

Pairing is not efficient for all tasks. Avoid it for simple, mechanical work like minor bug fixes or configuration changes, where the overhead of two developers is unnecessary. It can also be counterproductive for highly exploratory or research-oriented tasks where an individual needs unstructured time to experiment. Finally, it can fail if the two programmers have poor chemistry or if one person dominates the session without switching roles.

One canonical example

A senior and a junior developer are tasked with implementing a new authentication flow. The senior starts as the Navigator, explaining the security requirements and overall architecture. The junior drives, writing the code to connect to the identity provider. As they work, the senior spots a potential vulnerability in how a token is handled. They switch roles, and the senior drives to implement the fix while explaining the reasoning. This prevents a security flaw and upskills the junior developer simultaneously.