Pair programming efectivo: patrones que realmente funcionan

// 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...

## Hacer pair en esto:
- Lógica de negocio compleja (el navigator detecta errores de lógica)
- Discusiones de diseño de sistema (dos perspectivas encuentran mejores abstracciones)
- Investigaciones de bugs (uno lee código, otro formula hipótesis)
- Onboarding (el nuevo conduce, el desarrollador experimentado navega)
- Codebases poco familiares (la exploración colectiva es más rápida)
- Código sensible a la seguridad (cuatro ojos sobre auth y crypto)
 
## No hacer pair en esto:
- Operaciones CRUD simples y bien entendidas
- Cambios rutinarios en archivos de configuración
- Escribir documentación
- Tareas que requieren enfoque profundo y estado de flujo individual
- Refactorización mecánica (renombrar, extraer método)

// 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
}

## Checklist para pairing remoto:
1. Ambos participantes tienen VS Code Live Share instalado
2. Usa un canal de voz dedicado (Discord, Slack, Teams)
3. Comparte la terminal: ambos necesitan ejecutar comandos
4. Usa la función "Follow" para mantenerse en el mismo archivo
5. Anuncia los cambios de rol en voz alta: "Ahora conduzco yo"
6. Toma descansos cada 50 minutos: la fatiga de pantalla es 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)

## Patrones de comunicación del navigator:
 
✅ "Antes de implementar eso, ¿podemos conversar el enfoque
   durante 2 minutos? Quiero asegurarme de que estemos alineados con el flujo de datos."
 
✅ "Creo que hay un error de uno en la línea 15.
   ¿El índice debería empezar en 0 o en 1?"
 
✅ "Esta función se está haciendo larga. ¿Quieres extraer la
   validación a su propia función antes de continuar?"
 
✅ "Sugeriría usar un Map en lugar de un objeto aquí:
   necesitamos iteración ordenada."
 
❌ Sentarse en silencio y revisar Slack
❌ "Hazlo como quieras, revisaré el PR después"
❌ Agarrar el teclado sin preguntar
❌ Dictar cada pulsación: "Escribe const, espacio, user, equals..."

## Patrones de comunicación del driver:
 
✅ "Voy a probar primero el enfoque recursivo.
   Dime si ves una forma más simple."
 
✅ "Estoy atascado con este error de tipos. ¿Puedes leer la
   restricción genérica mientras yo miro el sitio de llamada?"
 
✅ "Déjame refactorizar esto primero: dame 3 minutos para
   extraer esto, y luego revisamos el diseño."
 
❌ Programar en silencio durante 20 minutos sin explicar la intención
❌ Ignorar las sugerencias del navigator

## Métricas que indican un pairing efectivo:
 
1. Tasa de defectos en código hecho en pair vs en solitario
   → Registra los bugs encontrados en code review o producción; etiquétalos como pair o solo
   → Objetivo: un 30-50% menos de defectos en código hecho en pair
 
2. Distribución del conocimiento
   → Bus factor: ¿cuántas personas pueden modificar cada módulo?
   → Objetivo: ningún módulo dependa de una sola persona que lo entienda
 
3. Tiempo de onboarding
   → Días hasta que un nuevo empleado envíe su primer PR en solitario
   → Objetivo: un 50% más rápido con onboarding en pair
 
4. Tiempo de revisión de PRs
   → El código hecho en pair recibe revisiones más ligeras (ya fue revisado en tiempo real)
   → Objetivo: los PRs de parejas se mergean un 40% más rápido
 
5. Satisfacción del desarrollador
   → Encuesta: "¿Sientes que hacer pair en [tipo de tarea] mejora la calidad?"
   → Objetivo: más del 70% de respuestas positivas

## Semana 1-2: introducción
- Haz pair en una tarea por sprint por persona
- Usa driver-navigator con cambios de 25 minutos
- Haz un debrief después de cada sesión: qué funcionó, qué se sintió incómodo
 
## Semana 3-4: encontrando el ritmo
- Haz pair automáticamente en tareas complejas
- Introduce el ping-pong pairing para tareas de TDD
- Reduce el debrief a un rápido "¿algo que ajustar?"
 
## Semana 5+: autosostenible
- Los desarrolladores inician pairing cuando encuentran complejidad
- No forzar el pairing en tareas simples
- Rotar compañeros para distribuir el conocimiento