Pair Programming

Also Known As

TL;DR

Explanation

Pair programming (from Extreme Programming) has the driver write code while the navigator reviews, considers the bigger picture, and catches mistakes in real time. Pairs switch roles regularly. Benefits include: immediate code review, shared knowledge preventing silos, higher design quality from continuous discussion, and faster onboarding. Studies show it produces fewer defects at a modest productivity cost. Remote pairing tools (VS Code Live Share, JetBrains Code With Me) make it viable for distributed teams. Not all tasks benefit equally — exploratory or complex tasks see the most gain.

Common Misconception

Why It Matters

Common Mistakes

• One person driving while the other passively watches — both must be actively engaged.
• Not switching driver/navigator roles frequently enough — one person dominates.
• Pairing as a productivity metric tool — it is a quality and knowledge-sharing tool, not an output maximiser.
• Never pairing — lone developer silos cause knowledge concentration and missed design opportunities.

Code Examples

// Pairing anti-pattern — one person types, other watches:
Developer A: [typing intensely]
Developer B: [watching YouTube on phone]
// No knowledge transfer, no second perspective, no benefit

// Productive pairing:
Developer A (navigator): 'We should validate the email before saving'
Developer B (driver): [typing validation] 'Good catch — should we also check uniqueness?'
Developer A: 'Yes, let's add that test first'

# Pair programming patterns for PHP teams

# Driver-Navigator:
# Driver: writes code
# Navigator: reviews in real-time, thinks ahead, spots issues
# Switch every 25 minutes (Pomodoro)

# Ping-Pong (TDD pairing):
# Dev A writes a failing test
# Dev B makes it pass, then writes next failing test
# Dev A makes it pass → repeat

# Tools for remote pairing:
# VS Code Live Share — shared editing, terminals, debugging
# JetBrains Code With Me — PhpStorm native
# tmux + Vim — terminal-based, ultra-low latency

# Benefits:
# - Knowledge transfer (no bus factor for critical paths)
# - Real-time code review (fewer PR back-and-forths)
# - Architecture decisions made together (fewer rewrites)

# Start with 20% of dev time — high-complexity or high-risk work

References

• ↗ https://www.extremeprogramming.org/rules/pair.html

Tags

Related Terms