Lo que el ‘Pairing’ ha hecho de mí: porque dos cabezas siempre piensan más que una

Me llamo Mikel y soy desarrollador backend en Biko. Me presento porque es la primera vez que escribo en el blog. Vengo a hablar de una de las primeras cosas que he aprendido durante el tiempo que llevo en Biko (entré en febrero de 2019): el valor del trabajo en pareja o como es más conocido, el pair programming. Para ello que voy a ponerme en contexto primero.

Entré en Biko siendo estudiante de Ingeniería Informática de la Universidad Pública de Navarra. La UPNA ofrecía prácticas en Biko, entre otros lugares, y la verdad que pude optar a la plaza de chiripa. Mis primeros pasos fueron en un proyecto que ya tenía un largo recorrido y eso hizo que viera qué era trabajar con el cliente día a día, semana a semana.

Pero mi verdadera formación empezó después. Ya con el proyecto entregado tuvimos un impasse en el verano de 2019 que fue muy valioso para mí, porque comenzaron a formarme en diversos aspectos: arquitectura hexagonal, asertividad en revisiones de código, trabajar con legacy code… y fue entonces cuando vi por primera vez lo que es el pairing. 🙂

Primeros pasos

Pasé a la acción y empecé a trabajar codo con codo con la gente de Familiados. Recuerdo que Ismael estaba mentorizando en aquel momento a un chico de Familiados (Alberto) y a mí en cómo trabajar en pareja y poder revisar nuestro código mutuamente. Durante esa primera etapa trabajábamos en vivo y en directo cuatro días a la semana para hacerlo más cercano, así podíamos ver los errores y las decisiones del otro.

El tipo de pairing con el que trabajábamos era el descrito como novel-novel (novice-novice).  Es cierto que es una práctica no recomendada si hay una falta de un rol modelo que ayude a asentar unas buenas prácticas de desarrollo. Pero, en nuestro caso, esa era la razón por la cual Isma venía con nosotros a la sala blanca, para que actuara como supervisor.

De esta primera experiencia saqué muchísimas cosas de valor que he aplicado desde entonces prácticamente a diario. El simple hecho de ver cómo dos personas novel enfocábamos el mismo problema me enseñó a observar el mismo problema desde distintos ángulos, a valorar adecuadamente el trabajo de los demás y a darme cuenta de lo valioso que es afrontar los grandes inconvenientes en grupo, en lugar de hacerlo solo. Si nos pasamos al ámbito técnico, fue una formación en la que trabajamos con código legado, aparte de los valores mencionados anteriormente, aprendí a refactorizar piezas de código bastante complejas.

Dos programadores haciendo ‘Pair Programming’

Más código y más retos

Unos meses después me enfrenté a la siguiente experiencia de pairing. Empezamos a trabajar en el equipo en un proyecto bastante complejo y compartí unos meses con otro compañero, Koldo. Un desarrollador con muchos años de experiencia a sus espaldas a quien en aquel entonces yo veneraba por lo rápido que encontraba la solución a cualquier problema. Se notaba que controlaba el tema, por eso pude aprender de él herramientas y tips que me han servido más adelante, esta fue la experiencia experto-novel (expert-novice) que me sirvió para comprender los pilares y los procesos del pair programming, trabajando en vivo y en directo con un código nada fácil y mano a mano con un senior. Casi nada.

No disponíamos del tiempo que nos hubiera gustado tener para más sesiones de pairing. La mayoría de las veces me limitaba a aprender del maestro, aunque sí que es cierto que a mi mente curiosa le daba algún quebradero de cabeza con las dudas que me iban surgiendo de vez en cuando. 

Esta vez aprendí a optimizar el tiempo. Koldo fue quien me enseñó que hay muchas cosas que no necesariamente tienes que picarlas a mano, sino que puedes buscarlas en las librerías, se podría decir que hay una librería para casi todo. Además, me enseñó la importancia de tener un flujo de trabajo limpio y ordenado, para que el resto del trabajo fuera más fluido. Juntos enfrentamos problemas técnicos complejos y me quedé con parte de las técnicas que él usaba a la hora de escribir código. Desde luego que hay gente que maneja el teclado de unas formas que se me hacían impensables hace un par de años…

Broche final 

Los meses posteriores se complicó la situación: confinamiento, trabajo remoto constante, un cambio de aires completo… Las circunstancias provocaron cambios que terminaron por hacer de Mauro un nuevo miembro del equipo y mi compañero de desarrollo de Backend. Así que, literalmente, estaba frotándome las manos, se me presentó una gran oportunidad para ir aprendiendo y avanzando más. Pero, lo cierto, es que me llegué a sorprender de mí mismo, porque le seguía el ritmo a Mauro.

Después de todo este tiempo de formación, de experiencia con unos y otros, de horas trabajadas por mi cuenta, llegó mi última experiencia en pareja, con Mauro. Nos tocaba afrontar un tema complejo del proyecto y decidimos hacerlo en pareja para beneficio mutuo: él adquiría contexto de la aplicación y yo continuaba con mi aprendizaje. Pero gracias al bagaje que tenía de las experiencias anteriores, resultó ser un ejercicio más cercano al denominado experto-experto (expert-expert).

Nos dedicábamos a debatir matices sobre conocimientos que ya teníamos asentados los dos. La mayor parte de las veces estábamos de acuerdo, por lo que los cambios que ambos puntualizábamos eran maneras de optimizar lo que hacía el otro. Lo cierto es que, noté que había madurado un poco más estos últimos meses por cómo me comportaba en las sesiones que teníamos y me sentí muy bien con ello.

Pantalla de código

En este periodo he aprendido mucho sobre arquitecturas limpias, procedimientos para mantener intacta la estructura del código antiguo y añadir funcionalidades que, de hacerse sin cuidado, alterarían los casos de uso ya existentes. Mauro me enseñó a coger el código con mimo y a no romper nada mientras sigues haciendo crecer la aplicación. Como si fuese una persona que siempre es capaz de hacer un nuevo movimiento en el jenga.

La conclusión que me llevo después de meses trabajando y avanzando en el pair programming es que apostar por este modelo hace que a la larga el código sea más limpio y se ahorre en costes y en tiempo. Siempre es un buen momento para darle la oportunidad al trabajo en pareja, y más ahora que con el teletrabajo no compartimos oficina, compartamos hangout.