Remote Mob Programming: programar juntos

Hace un tiempo terminé de leer el libro Remote Mob Programming y me dejó pensando: ¿qué pasaría si todo el equipo trabajara en la misma tarea, al mismo tiempo, en el mismo “espacio” virtual y en el mismo código compartido?

La idea viene de Woody Zuill, quien definió el mob programming original como:

“Todas las personas brillantes trabajando en lo mismo, al mismo tiempo, en el mismo espacio, y en la misma computadora.”

La versión remota simplemente cambia ese “mismo espacio” por una videollamada. Y, lejos de ser una desventaja, muchos equipos descubrieron que funciona incluso mejor que en persona.

⚙️ Cómo funciona técnicamente

En una sesión de mob remoto, no todo el mundo teclea a la vez (sería un caos). Se distinguen dos roles:

Driver 🚗: la persona que tiene el teclado y comparte pantalla. Escribe lo que el equipo decide.
Navegadores 🧭: el resto del grupo, que discute, revisa y guía al Driver.

La clave: los roles rotan frecuentemente. Lo habitual es marcar turnos cortos (10-15 minutos) con un temporizador. Cuando se agota el tiempo, el Driver hace commit/push de lo avanzado y otro compañero toma el relevo.

Un ciclo típico:

Todos en la videollamada, cámaras encendidas.
Se define el primer Driver y se arranca el temporizador.
Se trabaja en pasos pequeños (idealmente con TDD).
Al sonar el temporizador, commit, push y cambio de rol.
Repetir hasta el final de la sesión.

Herramientas como mob.sh o Git Mob automatizan parte del flujo de commits y co-autores para que el traspaso sea rápido y transparente.

🛠️ Herramientas y buenas prácticas

Videollamada estable: Zoom, Meet, Teams o Tuple, pero con audio y vídeo claros. Con un huddle de slack incluso puedes «pintar» en la pantalla.
IDE compartido: normalmente se usa pantalla compartida, pero hay muchas herramientas como «code with me» de Jetbrains
Pizarras digitales: Miro, Mural, excalidraw… para los diagramas que antes dibujaríamos en la pizarra física.
Pausas regulares ⏱️: cada 45-60 minutos, parar. La fatiga en mob llega más rápido. Esto es lo más importante
Equipo pequeño: 3–6 personas es lo ideal. Con más, algunos terminan invisibles.

Y algo muy importante: que todos estén remotos en igualdad de condiciones. Si unos están juntos en una sala y otros conectados desde casa, los remotos se quedan fuera de la conversación.

🤔 ¿Qué se gana programando así?

Menos bugs: todo el código está revisado en tiempo real.
Conocimiento compartido: nadie es “la única persona que sabe hacer X”.
Aprendizaje acelerado: un junior como Driver aprende a pasos agigantados con seniors guiándole. Aunque hay que tener cuidado con esto, más adelante lo comentamos
Más resiliencia: el bus factor mejora; si alguien falta, el resto sabe exactamente en qué estaba el trabajo.
Más cohesión: el equipo trabaja literalmente “codo con codo” (aunque sea en remoto).

Algunos equipos llegan a mobprogramar jornadas enteras. Otros lo reservan para tareas críticas o exploratorias. La intensidad es alta, pero también lo son los resultados.

🧑‍🤝‍🧑 Cultura: lo que hace que funcione

Aquí está la clave: sin cultura, el mob programming no pasa de ser una reunión larga con gente mirando una pantalla.

Para que funcione, necesitas:

Seguridad psicológica 🛡️: que todos puedan opinar y equivocarse sin miedo.
Confianza: tanto dentro del equipo como de la organización (sí, es normal que un manager se asuste al ver a 3,4 personas en una sola tarea, pero los resultados hablan por sí solos).
Empatía: entender el ritmo y las fortalezas de cada persona.
Mejora continua: micro-retros al final de cada sesión: ¿qué podemos ajustar para que la próxima sea mejor?

Al final, lo más potente del mob programming no es el código. Es lo que hace con el equipo:

rompe silos,
acelera el aprendizaje,
genera cohesión,
y devuelve el disfrute por programar acompañado.

🚀 Take aways: consejos que pueden serte útiles

El mob/pairing programming es una de esas prácticas que a veces generan amor y odio. Para algunas personas, es perder el doble de tiempo en una tarea. Para otras, es una de las formas más potentes de aprender, compartir conocimiento y mejorar la calidad del software.

La realidad suele estar en un punto intermedio: bien hecho, el pairing es una herramienta brutal; mal hecho, puede ser una tortura.

Aquí van algunos puntos y consejos que me han funcionado, basados en experiencias reales:

🕵️‍♂️ Micromanagement: cuidado con los detalles

Si eres el navegante, evita dar instrucciones como si estuvieras dictando código letra por letra.
A veces, cuando tu compañero no conoce el stack o la librería, sí que necesitas bajar a ese nivel de detalle… pero siempre con consentimiento.

La clave está en acompañar sin ahogar.

📅 No planifiques solo el código

Antes de arrancar, compartid vuestros planes del día:

¿Tienes reuniones o interrupciones previstas?
¿Cuál es el objetivo de la sesión?

Definir los objetivos de la jornada hace que ambos sepan a qué juegan. Y si uno no puede terminar la tarea entera, mejor dejarlo claro desde el inicio.

🔋 Sé honesto con tu energía

Todos tenemos días buenos y malos. Si hoy estás sin batería o con la cabeza en otra cosa, dilo.
No hay nada peor que fingir normalidad y estar frustrado en silencio.

🐇 Evita las madrigueras del conejo

Estáis en el frontend y de repente alguien recuerda una librería chula que vio el fin de semana.
Resultado: 20 minutos en npmjs en lugar de avanzar en el ticket.

Las conversaciones tangenciales son inevitables, pero intenta no perder el foco. Apunta la idea y retómala en el café o en un canal de Slack.

😤 Impaciencia y la regla de los 5 segundos

Cuando ves a tu pareja equivocarse, tu instinto puede ser corregir al instante.
En vez de saltar, espera 5 segundos.

Muchas veces, en ese margen, la otra persona se dará cuenta sola y corregirá. Y si no, ya tienes la oportunidad de guiar sin parecer un corrector automático.

🔨 Herramientas y entorno limpio

Si Live Share (o tu herramienta de pairing) falla, buscad un workaround rápido.
Desactiva notificaciones: nada mata más el foco que un Slack haciendo ping cada dos minutos.

El pairing requiere concentración mutua.

🧘‍♂️ No todo hay que hacerlo en pareja

Hay tareas rutinarias, mecánicas o aburridas (ej. actualizar propiedades de configuración) que no necesitan pairing.
Reservad el tiempo de pairing para tareas donde haya aprendizaje, exploración o decisiones que se beneficien de dos perspectivas.

⏱️ Pausas y tiempos humanos

Estar dos horas pegados a una pantalla cansa mucho más que trabajar en solitario.

Una buena regla: 50 minutos de trabajo, 10 de descanso.
Incluso en remoto, levantaros, bebed agua, despejad la cabeza.

🤝 Diversidad, empatía y niveles de experiencia

El pairing no es lo mismo con un senior que con alguien que acaba de empezar.
Si estás con alguien más junior:

Baja un poco la velocidad.
Pregunta si entiende lo que estáis haciendo.
Anímale a externalizar su pensamiento en voz alta.

Lo ideal es un ciclo: tú muestras, explicas y luego cedes el teclado para que tu compañero lo repita. Así consolida el aprendizaje.

Ejemplo real: cuando un colega quiso aprender Backend, primero le mostré cómo crear un caso de uso, luego le dejé a esa persona escribirlo mientras yo preguntaba “¿qué harías ahora?” y le corregía con calma. Lo que para mí eran 5 minutos, para él era un reto de media hora. Pero el conocimiento se quedó.

⚽ La clave: objetivos compartidos

Pair programming no es que alguien te enseñe a programar, ni que alguien “trabaje por ti”.
Es un proceso compartido con objetivos claros:

Entender mejor el problema.
Aprender del otro.
Llegar a una solución de mayor calidad.

Cuando lo enfocamos así, el pairing deja de ser una obligación y pasa a ser una inversión en equipo y conocimiento colectivo.

📌 Conclusión

El Remote Mob Programming no es solo una técnica para escribir código: es una forma de trabajar como un verdadero equipo.

Requiere disciplina técnica (rotaciones, commits pequeños, herramientas que funcionen) pero, sobre todo, una cultura de confianza, comunicación y aprendizaje compartido.

Si tu equipo siente que está fragmentado, que cada uno va por su cuenta o que el conocimiento está demasiado centralizado, prueba con una sesión de mob. Empiecen con algo pequeño, roten rápido, hagan pausas, y sobre todo: hablen.

Quizás descubran que programar juntos en remoto es mucho más que escribir código: es construir equipo.

Jesús L.C. – Apuntes de un aprendiz