Pair Programming

Pair programming significa dos desarrolladores trabajando juntos en una estación de trabajo. Uno escribe (el conductor); el otro observa, piensa y navega (el navegador).

Esto parece ineficiente. Estás pagando a dos personas para hacer el trabajo de una. Pero las matemáticas funcionan diferente de lo que esperarías:

• Menos bugs llegan a producción (el navegador detecta errores en tiempo real)
• El conocimiento se distribuye por el equipo (no hay silos de conocimiento)
• La calidad del código mejora (revisión de código en tiempo real)
• Los desarrolladores junior suben de nivel más rápido (aprendiendo de los seniors)
• El enfoque mejora (es más difícil revisar Twitter cuando alguien está mirando)

Los estudios muestran que las parejas producen código con 15% menos defectos mientras toman solo 15% más tiempo. Eso no es el doble del costo por mejor calidad—es una inversión del 15% para resultados dramáticamente mejores.

El modelo clásico de pair programming tiene dos roles:

El Conductor sostiene el teclado. Ellos:

• Escriben el código
• Se enfocan en la tarea inmediata (sintaxis, esta línea, esta prueba)
• Piensan tácticamente sobre la implementación
• Hablan sobre lo que están haciendo

El Navegador observa y piensa. Ellos:

• Revisan el código mientras se escribe
• Piensan estratégicamente (¿tiene sentido este diseño?)
• Mantienen en mente el panorama general
• Detectan errores tipográficos, errores de lógica y problemas de diseño
• Buscan información cuando es necesario

Cambien de roles regularmente. Cada 15-30 minutos, intercambien. Esto mantiene a ambos compañeros comprometidos y evita que una persona domine.

El navegador no es pasivo. Si estás navegando y ves algo mal, habla inmediatamente. No esperes. El valor del pair programming viene de la retroalimentación continua.

Hay varios estilos efectivos de pair programming:

Ping-Pong Pairing (funciona genial con TDD):

1. La Persona A escribe una prueba que falla
2. La Persona B la hace pasar y escribe la siguiente prueba que falla
3. La Persona A la hace pasar y escribe la siguiente prueba que falla
4. Continúan alternando

Esto mantiene a ambas personas codificando activamente y mantiene la disciplina de TDD.

Strong-Style Pairing: "Para que una idea vaya de tu cabeza a la computadora, debe pasar por las manos de otra persona."

El navegador le dice al conductor qué escribir. El conductor solo escribe; no toma decisiones. Esto es genial para enseñar—el junior escribe mientras el senior navega, forzando la transferencia de conocimiento.

Tour Guide Pairing: Una persona conoce el código base; la otra está aprendiendo. El experto conduce y explica, dando un tour del código. Luego intercambian, con el aprendiz intentando tareas bajo guía.

Elige el estilo que se ajuste a la situación. Ping-pong para TDD. Strong-style para mentoría. Tour guide para incorporación.

El pair programming también funciona de forma remota. Necesitas:

• Compartir pantalla con baja latencia (VS Code Live Share, JetBrains Code With Me, o compartir pantalla con control remoto)
• Comunicación por voz (conexión de audio constante)
• Cámara opcional pero útil (ver reacciones y lenguaje corporal)

Consejos para pair programming remoto:

• Usa una herramienta que permita a ambas personas escribir (no solo compartir pantalla)
• Toma descansos más frecuentes—el pair programming remoto es más agotador
• Comunícate verbalmente en exceso (no puedes leer el lenguaje corporal tan bien)
• Acuerden configuraciones del editor y atajos de teclado antes de comenzar

Algunos equipos encuentran que el pair programming remoto funciona incluso mejor que en persona porque no hay tentación de "inclinarse y tomar el teclado". Cada persona permanece en su rol.

Haz pair programming en:

• Problemas complejos donde dos perspectivas ayudan
• Rutas de código críticas (autenticación, pagos, integridad de datos)
• Código desconocido (una persona lo conoce, una está aprendiendo)
• Cuando estás atascado (una perspectiva fresca rompe bloqueos)
• Incorporación de nuevos miembros del equipo

Considera trabajo individual para:

• Tareas simples y rutinarias (actualizar configuración, renombrar cosas)
• Exploraciones (cuando necesitas pensar solo)
• Cuando una persona tiene experiencia profunda a la que la otra no puede contribuir

XP no exige 100% de pair programming, a pesar de la creencia común. El XP original especificaba pair programming para código de producción, pero el XP moderno reconoce que los equipos efectivos mezclan trabajo individual y en pareja según el contexto.

La clave: nunca dejes que el código llegue a producción sin revisión. Si no haces pair programming en él, revísalo. El pair programming es solo revisión de código en tiempo real.

"Nuestros desarrolladores no quieren hacer pair programming." Comienza lentamente. Haz pair programming solo en problemas difíciles. Deja que las personas experimenten los beneficios. No fuerces 100% de pair programming desde el primer día.

"No podemos permitirnos dos personas en una tarea." Tampoco puedes permitirte bugs de producción. La economía favorece el pair programming cuando consideras la reducción de bugs, el conocimiento compartido y la calidad de código mejorada.

"Los desarrolladores senior se verán ralentizados." A veces. Pero los seniors haciendo pair programming con juniors aceleran a todo el equipo. El conocimiento del senior se distribuye. El junior sube de nivel. Es una inversión en la capacidad del equipo.

"Los introvertidos odian el pair programming." Algunos introvertidos aman el pair programming porque es interacción estructurada con un propósito claro. Otros necesitan tiempo a solas para recargarse. Respeta las necesidades individuales, pero no asumas que introversión significa anti-pair programming.

"El pair programming es agotador." Es más intenso que el trabajo individual. Toma descansos. No hagas pair programming durante 8 horas seguidas. Mezcla pair programming con trabajo individual, revisión de código o trabajo de diseño.