top of page

Pair Programming That Helps — Mentoring Engineers, Part 2

Shawn West
14 minutes ago
3 min read

Pairing transfers tacit knowledge faster than docs. Done right: junior learns 6 months in 2 weeks. Done wrong: senior frustrated, junior dependent.

Step 1: Driver and Navigator (10 min)

Two roles:

  • Driver — at the keyboard; types

  • Navigator — thinks ahead; reviews; suggests

Switch every 15-30 minutes. Both engaged.

Common failure: senior drives the whole time. Junior watches. Learning weak.

Reverse it: junior drives more. They learn by typing.

Step 2: Senior Drives First (Demo) (10 min)

For the first time touching an area:

  • Senior drives; explains while typing

  • "I'm going to start by..."

  • "I'm looking at this because..."

  • "I considered X but rejected because..."

Talk through the thinking. Junior absorbs the "how to approach" not just the "what to type."

15-30 minutes max. Then switch.

Step 3: Junior Drives (Practice) (10 min)

  • Junior at keyboard

  • Senior watches; doesn't grab keyboard

  • Says "what would you try?" when junior is stuck

  • Hints; doesn't solve

Resist the urge to take over. Even when slow.

The slowness is the learning.

Step 4: Set Time Limits (5 min)

2-3 hour sessions max.

  • Both fresh enough to think

  • Junior doesn't feel watched all day

  • Senior doesn't sacrifice their week

Schedule. Stop on time.

For longer work: schedule multiple shorter sessions across days.

Step 5: Pair on the Right Things (10 min)

Great for pairing:

  • New code area for the junior

  • Tricky algorithm / design

  • Bug hunting in unfamiliar code

  • Code review with mentoring intent

Bad for pairing:

  • Routine CRUD work

  • Independent work that's already understood

  • Boring infrastructure tasks

Choose pair tasks deliberately.

Step 6: Voice the Why (10 min)

"I'm naming it `userByEmail` not `getUser` because..."
"I'm choosing a map here because of..."
"I'd normally write a test first because..."

The why is the lesson. Without it, pairing teaches typing.

Repeat for every choice. Annoying briefly; powerful long-term.

Step 7: Let Them Be Wrong (10 min)

Junior wants to use approach X. Senior would use Y.

Sometimes: let X play out.

"I'd do Y. But let's try X for 30 minutes; see what we learn."

X might be:

  • Actually fine (you were wrong)

  • Educational failure (junior learns)

  • Slightly worse (acceptable)

Always overriding = junior never grows judgment.

Step 8: Pause for Reflection (5 min)

At the end:

"What did you learn?"
"What surprised you?"
"What would you do differently?"

5 minutes. Captures the lesson.

Without this, pairing rolls into a blur.

Step 9: Remote Pairing (15 min)

VS Code Live Share, JetBrains Code With Me, tmux, etc.

For remote teams:

  • Video on

  • Share screen

  • Tools for shared cursor

  • 90-minute sessions max (Zoom fatigue)

Less rich than in-person. Still highly valuable.

Async pairing: PRs with detailed comments + code suggestions. Slower; works for distributed teams.

Step 10: Know When to Stop (5 min)

Pairing isn't permanent. Goal: junior eventually doesn't need it.

Signs they're ready to solo:

  • They drive most of the session

  • They catch their own mistakes

  • They explain their approach unprompted

  • They push back on your suggestions (with reasons)

Step back. They'll struggle some. That's growth.

What You Just Did

Pairing: driver/navigator, demo + practice, time limits, right tasks, voice the why, let them be wrong, reflect, remote, know when to stop. Knowledge transfer that compounds.

Common Failure Modes

Senior drives whole time. Junior watches; learns less.

Take the keyboard at every snag. Junior never solves anything.

8-hour pair sessions. Both fried.

Pair on routine work. Wastes everyone's time.

Never step back. Junior dependent forever.

bottom of page