engineering-pair-programming

Pair programming techniques, driver-navigator roles, mob programming, remote pairing tools and best practices

Pair Programming & Mob Programming

Scope: Comprehensive guide to pair programming, mob programming, remote pairing, and collaborative coding practices Lines: ~280 Last Updated: 2025-10-27 Format Version: 1.0 (Atomic)

When to Use This Skill

Activate this skill when:

Onboarding new team members
Solving complex problems
Sharing knowledge across team
Establishing coding standards
Reviewing critical code live
Learning new technologies
Breaking through development blockers
Building team cohesion

Core Concepts

Concept 1: Driver-Navigator Pattern

Driver: Person typing/coding

Focus on tactical implementation
Write code, run tests
Think about syntax and details

Navigator: Person guiding

Focus on strategic direction
Think about design and architecture
Catch errors and suggest improvements

Switch Roles: Every 15-25 minutes

┌─────────────────────────────────────┐
│ Navigator: "Let's extract this      │
│ validation logic into a function"   │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│ Driver: *types function extraction* │
│ "Like this?"                        │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│ Navigator: "Yes, but let's make it  │
│ return early on invalid input"      │
└─────────────────────────────────────┘

Concept 2: Pairing Styles

Ping-Pong Pairing (with TDD):

1. Person A: Write failing test
2. Person B: Make test pass
3. Person B: Refactor
4. Person B: Write next failing test
5. Person A: Make test pass
6. Repeat...

Strong-Style Pairing:

"For an idea to go from your head to the computer, it must go through someone else's hands"

Navigator has idea
Driver implements (doesn't think independently)
Forces clear communication
Great for teaching

Unstructured Pairing:

Fluid role switching
Both contribute equally
Works well for experienced pairs

Concept 3: Mob Programming

Definition: Entire team works on same code at same time

Setup:

One driver, multiple navigators
Rotate driver every 10-15 minutes
Large screen visible to all
Timer for rotations

Benefits:

Maximum knowledge sharing
Real-time code review
No handoffs or context switching
Team alignment

Patterns

Pattern 1: Effective Pairing Session

Before Session:

1. Define goal (30 seconds)
   "We're implementing user authentication"

2. Agree on approach (2 minutes)
   "Let's use JWT tokens and bcrypt for passwords"

3. Set time box (1-2 hours)
   "Let's pair until lunch"

4. Choose roles
   "I'll drive first, you navigate"

During Session:

Switch roles every 15-25 min
Take breaks together
Communicate constantly
Think out loud

After Session:

Commit and push code
Reflect on what worked
Document learnings

Pattern 2: Communication Patterns

Good Communication:

Navigator: "Let's add error handling for the null case"
Driver: "Good catch. Like this?" *types*
Navigator: "Yes, but we should also log the error"
Driver: "Makes sense" *adds logging*

Bad Communication:

Navigator: "That's wrong"
Driver: "Why?"
Navigator: "Just change it"
Driver: "To what?"
Navigator: *grabs keyboard* "Like this!" ← Anti-pattern!

Best Practices:

Be specific: "Let's extract lines 45-50 into a function"
Ask questions: "What if the user is null?"
Acknowledge: "Good idea, let's try that"
Never grab keyboard without permission

Pattern 3: Remote Pairing Setup

Tools:

Screen Sharing:
- VS Code Live Share (best for coding)
- Tuple (low latency, great for pairing)
- Zoom/Google Meet (screen share + audio)

Code Collaboration:
- VS Code Live Share: Real-time editing
- JetBrains Code With Me: IntelliJ pairing
- tmux: Terminal multiplexing

Communication:
- Discord: Low latency voice
- Slack huddle: Quick screen share
- Tuple: Built-in voice chat

VS Code Live Share Example:

# Host starts session
# Share link with pair

# Guest joins
# Both can edit, run terminal, debug

# Benefits:
# - No lag (local editing)
# - Each person uses own setup
# - Shared terminal and debugger

Pattern 4: Pairing with Skill Gaps

Expert + Novice:

Strong-Style Pairing:
- Novice drives (hands on keyboard)
- Expert navigates (teaches)
- Forces expert to explain clearly
- Novice learns by doing

Example:
Expert: "Let's create a new function called validate_email"
Novice: *types function signature*
Expert: "Good, now add a parameter for the email string"
Novice: *adds parameter*
Expert: "What should we check first?"
Novice: "If it contains an @ symbol?"
Expert: "Exactly! Go ahead and write that"

Two Experts:

Unstructured Pairing:
- Fluid role switching
- Both contribute ideas equally
- Quick knowledge exchange
- Focus on hard problems

Pattern 5: Mob Programming Session

Roles:

Driver: Types code (hands, not brain)
Navigator: Guides driver (thinks strategically)
Mob: Suggests ideas to navigator

Rotation:

Every 10 minutes:
Driver → Mob (rest)
Navigator → Driver (implement)
Mob member → Navigator (think)

Example Session:

10:00 - Alice drives, Bob navigates, team suggests
10:10 - Bob drives, Carol navigates, team suggests
10:20 - Carol drives, Dave navigates, team suggests
10:30 - Dave drives, Alice navigates, team suggests
10:40 - Break (5 min)

Best Practices

Pairing Etiquette

Do's:

Be present (no phone, no email)
Communicate constantly
Think out loud
Take breaks together
Switch roles regularly
Be patient and respectful
Ask "why" not "what"

Don'ts:

Don't grab keyboard
Don't work in silence
Don't dominate session
Don't check phone/email
Don't skip breaks
Don't criticize personally
Don't pair for 8 hours straight

When to Pair

Good Times to Pair:

Critical features (auth, payments)
Complex algorithms
Unfamiliar codebases
Onboarding new engineers
Breaking through blockers
Establishing patterns

Bad Times to Pair:

Trivial tasks (simple bug fixes)
Routine work (updating docs)
Deep research (exploring options)
Individual learning time
When tired or unfocused

Optimal Pairing Duration

Session Length: 1-2 hours
Break: 5-10 minutes
Daily Pairing: 4-6 hours max

Schedule Example:
09:00-10:30: Pair session 1
10:30-10:40: Break
10:40-12:00: Pair session 2
12:00-13:00: Lunch (separate)
13:00-14:30: Pair session 3
14:30-16:00: Solo work

Don't pair 100% of time - solo work is valuable!

Anti-Patterns

Common Pairing Mistakes

❌ Watch-the-Master
→ One person codes, other watches silently
✅ Active navigation and communication

❌ Keyboard Hogging
→ Driver refuses to switch
✅ Time-box rotations (15-25 min)

❌ Back-seat Driving
→ Navigator dictates every keystroke
✅ Navigate strategically, not tactically

❌ Pairing 8 Hours Straight
→ Exhausting and ineffective
✅ 4-6 hours max, with breaks

❌ Pairing on Everything
→ Waste time on trivial tasks
✅ Pair on complex, critical work

❌ Silent Pairing
→ No communication, no collaboration
✅ Think out loud, discuss constantly

❌ Unequal Participation
→ One person dominates
✅ Equal time as driver/navigator

Remote Pairing Tips

Making Remote Pairing Effective

Technical Setup:

# High-quality audio crucial
- Use headphones (reduce echo)
- Use quality mic (not laptop mic)
- Test audio before session

# Screen sharing
- Share entire screen (not just window)
- Increase font size (18-20pt)
- Use high-contrast theme
- Hide distracting notifications

# Collaboration tools
- VS Code Live Share: Shared editing
- Shared terminal: Both can type
- Shared debugger: Both can step through

Communication:

# Over-communicate (no body language)
"I'm thinking..." (when silent)
"Let me drive next" (before grabbing control)
"Can you try...?" (instead of just doing it)

# Use video when possible
- See facial expressions
- Read body language
- Build rapport

Measuring Success

Pairing Effectiveness Metrics

Qualitative:

Knowledge shared between team members
Fewer bugs in production
Faster onboarding
Improved code quality
Team cohesion

Quantitative:

Defect rate (should decrease)
Code review time (should decrease)
Time to production (may increase initially)
Bus factor (should increase)

Team Surveys:

Weekly Pairing Retrospective:
1. What worked well?
2. What could improve?
3. Did you learn something new?
4. Was pairing time well spent?
5. Would you pair on this task again?

Code Example: Pairing Session

Ping-Pong TDD Session:

# Person A: Write failing test
def test_calculate_discount_for_vip():
    customer = Customer(type="VIP")
    discount = calculate_discount(customer, purchase_amount=100)
    assert discount == 20  # 20% discount for VIP

# Test fails (function doesn't exist)

# Person B: Make test pass (minimal implementation)
def calculate_discount(customer, purchase_amount):
    if customer.type == "VIP":
        return purchase_amount * 0.20
    return 0

# Test passes!

# Person B: Refactor
def calculate_discount(customer, purchase_amount):
    VIP_DISCOUNT_RATE = 0.20
    if customer.is_vip():  # Better abstraction
        return purchase_amount * VIP_DISCOUNT_RATE
    return 0

# Person B: Write next failing test
def test_calculate_discount_for_regular():
    customer = Customer(type="REGULAR")
    discount = calculate_discount(customer, purchase_amount=100)
    assert discount == 10  # 10% discount for regular

# Test fails (returns 0)

# Person A: Make test pass
def calculate_discount(customer, purchase_amount):
    VIP_DISCOUNT_RATE = 0.20
    REGULAR_DISCOUNT_RATE = 0.10

    if customer.is_vip():
        return purchase_amount * VIP_DISCOUNT_RATE
    return purchase_amount * REGULAR_DISCOUNT_RATE

# Tests pass! Continue...

Related Skills

engineering-code-review: Pair programming is live code review
engineering-test-driven-development: Ping-pong pairing with TDD
engineering-refactoring-patterns: Pair on refactoring
engineering-domain-driven-design: Pair to model domain