Effective Pair Programming: Patterns That Actually Work

// Example: Navigator spots an edge case as Driver writes
// Driver typing:
async function getUserOrders(userId: string): Promise<Order[]> {
  const user = await db.user.findUnique({ where: { id: userId } });
  const orders = await db.order.findMany({
    where: { userId },
    orderBy: { createdAt: 'desc' },
  });
  return orders;
}
 
// Navigator: "We're fetching user but not using it.
// Were you planning to check permissions?
// Also — what happens if userId doesn't exist?
// We should add a null check on user."
 
// Driver revises:
async function getUserOrders(userId: string): Promise<Order[]> {
  const user = await db.user.findUnique({ where: { id: userId } });
 
  if (!user) {
    throw new NotFoundError(`User ${userId} not found`);
  }
 
  return db.order.findMany({
    where: { userId },
    orderBy: { createdAt: 'desc' },
  });
}

// Round 1: Person A writes a failing test
describe('PasswordValidator', () => {
  it('rejects passwords shorter than 8 characters', () => {
    expect(validatePassword('abc')).toEqual({
      valid: false,
      errors: ['Password must be at least 8 characters'],
    });
  });
});
 
// Round 2: Person B makes it pass with minimal code
function validatePassword(password: string): ValidationResult {
  const errors: string[] = [];
 
  if (password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }
 
  return { valid: errors.length === 0, errors };
}
 
// Round 3: Person A writes the next test
it('requires at least one uppercase letter', () => {
  expect(validatePassword('abcdefgh')).toEqual({
    valid: false,
    errors: ['Password must contain at least one uppercase letter'],
  });
});
 
// Round 4: Person B extends the implementation
function validatePassword(password: string): ValidationResult {
  const errors: string[] = [];
 
  if (password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }
 
  if (!/[A-Z]/.test(password)) {
    errors.push('Password must contain at least one uppercase letter');
  }
 
  return { valid: errors.length === 0, errors };
}
 
// Continue alternating...

## Pair on these:
- Complex business logic (the navigator catches logic errors)
- System design discussions (two perspectives find better abstractions)
- Bug investigations (one reads code, one forms hypotheses)
- Onboarding (new hire drives, experienced dev navigates)
- Unfamiliar codebases (collective exploration is faster)
- Security-sensitive code (four eyes on auth and crypto)
 
## Don't pair on these:
- Simple, well-understood CRUD operations
- Routine config file changes
- Writing documentation
- Tasks requiring deep focus and individual flow state
- Mechanical refactoring (rename, extract method)

// This benefits from pairing — complex state machine with edge cases
function processPayment(order: Order, payment: Payment): PaymentResult {
  // Multiple states, retries, partial failures, compensating actions
  // Navigator catches: "What if the charge succeeds but inventory
  // reservation fails? We need a compensation step."
}
 
// This does NOT benefit from pairing — straightforward CRUD
async function updateUserEmail(userId: string, email: string) {
  return db.user.update({ where: { id: userId }, data: { email } });
}

// .vscode/settings.json — Live Share configuration for pairing
{
  "liveshare.autoShareServers": true,
  "liveshare.autoShareTerminals": true,
  "liveshare.focusBehavior": "prompt",
  "liveshare.guestApprovalRequired": false,
  "liveshare.shareExternalFiles": false
}

## Remote pairing checklist:
1. Both participants have VS Code Live Share installed
2. Use a dedicated voice channel (Discord, Slack, Teams)
3. Share the terminal — both need to run commands
4. Use the "Follow" feature to stay on the same file
5. Announce role switches verbally: "I'm driving now"
6. Take breaks every 50 minutes — screen fatigue is real

# Screen sharing with audio — for teams without VS Code
# tmux allows both participants to use the same terminal
# On host machine:
tmux new -s pairing
 
# On remote machine (via SSH):
tmux attach -t pairing
 
# Both see the same terminal, both can type
# Pair with any terminal-based editor (vim, nano, emacs)

## Navigator communication patterns:
 
✅ "Before we implement that — can we talk through the approach
   for 2 minutes? I want to make sure we're aligned on the data flow."
 
✅ "I think there's an off-by-one error on line 15.
   Should the index start at 0 or 1?"
 
✅ "This function is getting long. Want to extract the
   validation into its own function before we continue?"
 
✅ "I'd suggest using a Map instead of an object here —
   we need ordered iteration."
 
❌ Sitting silently and checking Slack
❌ "Just do it however you want, I'll review the PR later"
❌ Grabbing the keyboard without asking
❌ Dictating every keystroke: "Type const, space, user, equals..."

## Driver communication patterns:
 
✅ "I'm going to try the recursive approach first.
   Tell me if you see a simpler way."
 
✅ "I'm stuck on this type error. Can you read the
   generic constraint while I look at the call site?"
 
✅ "Let me refactor this first — give me 3 minutes to
   extract this, then let's review the design."
 
❌ Coding silently for 20 minutes without explaining intent
❌ Ignoring navigator suggestions

## Metrics that indicate effective pairing:
 
1. Defect rate in paired code vs solo code
   → Track bugs found in code review or production, tag paired vs solo
   → Target: 30-50% fewer defects in paired code
 
2. Knowledge distribution
   → Bus factor: how many people can modify each module?
   → Target: no module has only one person who understands it
 
3. Onboarding time
   → Days until new hire submits first solo PR
   → Target: 50% faster with pairing onboarding
 
4. PR review turnaround
   → Paired code gets lighter reviews (already reviewed in real-time)
   → Target: PRs from pairs merge 40% faster
 
5. Developer satisfaction
   → Survey: "Do you feel pairing on [task type] improves quality?"
   → Target: >70% positive response

## Week 1-2: Introduction
- Pair on one task per sprint per person
- Use driver-navigator with 25-minute switches
- Debrief after each session: what worked, what felt awkward
 
## Week 3-4: Finding the rhythm
- Pair on complex tasks automatically
- Introduce ping-pong pairing for TDD tasks
- Reduce debrief to a quick "anything to adjust?"
 
## Week 5+: Self-sustaining
- Developers initiate pairing when they hit complexity
- No forced pairing on simple tasks
- Rotate partners to spread knowledge