Programación en pareja efectiva: remota y presencial

## Driver responsibilities
- Type the code
- Think at the implementation level
- Focus on syntax, variable names, current line
- Ask clarifying questions about direction
- Don't rush — type at a pace the navigator can follow
 
## Navigator responsibilities  
- Think at the design level
- Watch for bugs the driver might miss
- Consider edge cases and error handling
- Keep the bigger picture in mind
- Suggest refactors when the driver is in the weeds
- DON'T dictate every keystroke — trust the driver
 
## Rotation cadence
- Switch every 25-30 minutes (Pomodoro-style)
- Use a visible timer both people can see
- Switch roles when hitting a natural break point
- The new driver continues from where the old driver left off

## Knowledge transfer pairing
Goal: Senior teaches junior a codebase area
Structure:
- Senior navigates, junior drives (70% of time)
- Junior asks questions while implementing
- Senior explains the "why" behind patterns
- Switch so junior navigates (tests understanding)
 
## Bug hunting pairing  
Goal: Find and fix a tricky production bug
Structure:
- Start with 10 minutes of shared context
  (both read error logs, traces, related code)
- Person A hypothesizes, Person B tries to disprove
- Swap hypothesis roles every 15 minutes
- Rubber-ducking effect catches wrong assumptions
 
## Design session pairing
Goal: Design a new feature's architecture
Structure:
- 15 min: both sketch independently (diverge)
- 15 min: present sketches and discuss trade-offs
- 30 min: driver implements agreed approach,
  navigator watches for design drift
- Review: did the implementation match the design?
 
## Refactoring pairing
Goal: Improve code without changing behavior
Structure:
- Write characterization tests together first
- Driver makes small changes, navigator watches 
  tests stay green
- Swap every refactoring step
- Never refactor and change behavior simultaneously

## Tool setup for remote pairing
 
### Screen sharing approach
- VS Code Live Share: shared editing, terminals, servers
- Better than screen share because both can type
- Navigator can jump to files independently
- No input lag — both edit the same workspace
 
### Communication
- Camera on (builds trust, catches confusion early)
- Use "thinking out loud" — narrate what you're doing
- "I'm going to look at the test file because..."
- "I notice this function doesn't handle null..."
 
### Dealing with latency
- Use shared editors (Live Share) over screen sharing
- If screen sharing, let the driver share their screen
- Navigator: wait 2 seconds before interrupting
  (lag makes it easy to talk over each other)
 
### What doesn't work remotely
- Mob programming with >3 people (too much latency)
- Long sessions without breaks (Zoom fatigue)
- Pairing without a clear goal (aimless and draining)

// Example: setting up a productive pairing session
interface PairingSession {
  goal: string;
  timeboxMinutes: number;
  rotationMinutes: number;
  participants: [string, string];
  currentDriver: string;
}
 
// ❌ Bad session: vague goal, no structure
const badSession: PairingSession = {
  goal: "Work on the user feature",
  timeboxMinutes: 240,  // 4 hours with no breaks
  rotationMinutes: 0,   // No rotation planned
  participants: ["Alice", "Bob"],
  currentDriver: "Alice", // Alice always drives
};
 
// ✅ Good session: specific goal, bounded time, rotation
const goodSession: PairingSession = {
  goal: "Implement password reset flow with email verification",
  timeboxMinutes: 90,
  rotationMinutes: 25,
  participants: ["Alice", "Bob"],
  currentDriver: "Alice",
};

## Senior + Junior pairing
 
### Common failure mode:
Senior drives fast, junior nods along, 
learns nothing, feels bad for "slowing down."
 
### Better approach:
1. Senior explains the task at a high level (5 min)
2. Junior drives, senior navigates
3. Senior asks leading questions instead of dictating:
   - "What would happen if this input were null?"
   - "Which pattern have we used for similar validations?"
   - "How would you test this?"
4. Senior only takes keyboard for demonstrating
   a specific technique (2-3 minutes max)
5. Junior drives again immediately after
 
### The junior's responsibility:
- Ask questions immediately when confused
- Don't pretend to understand — it wastes both people's time
- If you're lost, say "Can we step back? I lost the thread 
  at [specific point]"
- Take notes for areas to study after the session
 
### The senior's responsibility:  
- Calibrate explanation depth to the junior's level
- Resist the urge to take the keyboard
- Celebrate when the junior catches something you missed
- Remember: teaching solidifies your own understanding

## Skip pairing when:
- The task is pure mechanical work (renaming, formatting)
- One person needs deep focus on a novel algorithm
- Both people already understand the code and the task
- Someone is having a bad day and needs quiet focus
- The task is exploratory research (reading docs, prototyping)
 
## Always pair when:
- Onboarding a new team member
- Working on critical path / security-sensitive code
- Neither person fully understands the system
- You've been stuck on a bug for more than 30 minutes
- Making architectural decisions that affect the team
- The code change is high-risk and hard to revert
 
## Optional pairing (team preference):
- Feature implementation in familiar code
- Writing tests for existing code
- Code review follow-ups
- Documentation writing

## After each session (2-minute retro)
 
1. Did we achieve the session goal? (yes/no)
2. How balanced was the driving? (1-5)
3. What was the best moment? (one sentence)
4. What would we do differently? (one sentence)
 
## Weekly team metrics
 
- How many pairing sessions happened?
- What % of complex changes were paired on?
- Bug rate in paired vs solo code (over months)
- Knowledge distribution: can >1 person modify 
  each critical system?
- New member ramp-up time: is it decreasing?
 
## Signs pairing is working:
- Fewer "only Alice knows this" situations
- Code reviews are faster (reviewer already has context)
- Fewer bugs in paired code
- Team members voluntarily request pairing sessions
 
## Signs pairing needs adjustment:
- People avoid pairing or find excuses to skip
- Sessions consistently run over time
- One person always drives
- People feel drained rather than energized after sessions