Todos nos hemos visto en esta situación en algún momento: nos disponemos a trabajar en una característica o en un bug complejo. No estamos familiarizado con el código alrededor o simplemente estamos ante una situación más compleja de la que imaginábamos. Para esto, usualmente pedimos ayuda a algún compañero y usualmente hacemos una sesión de trabajo en equipo con el compañero de forma síncrona. Hemos iniciado una sesión de “pair programming” o “programación en pareja”.

Al iniciar este proceso de comunicación y de explicación de la situación, nos ayuda a entender muchas veces el problema de una mejor forma. En The Pragmatic Programmer, escrito por Dave Thomas, por primera vez leí el término “Rubber Duck Debugging”, el cuál se basa en explicarle a un patito de hule el problema que intentas resolver, línea a línea, para así entender a plenitud el trasfondo de la situación.

Este método se basa en la técncia Feynman de aprendizaje, que se podría resumir con la frase “si quieres aprender algo, debes poder enseñarlo a un niño pequeño”.

Muchas veces, con solo iniciar el proceso de explicarlo, damos con la solución a dicha situación. He pasado por esto cientos de veces con mi amigo y colega, Leonardo Moreno Jr.: entramos a una llamada, le explico una situación y al cabo de 2 minutos le digo “creo que ya sé que es, te llamo en unos minutos”.

Y es que a veces, el problema es más simple del que imaginamos; a veces la solución está en frente de nosotros, a veces incluso el compañero nos da una perspectiva totalmente diferente y nueva.

Los ingenieros solemos ser testarudos, tercos o hasta intransigentes. Sin embargo, a veces es bueno pedirle ayuda, aunque sea al “patito de hule”.

En contraste, las sesiones de trabajo en pareja a veces pueden ser pesadas, pueden robarnos energía o hasta desconcentrarnos del objetivo real. Para ello, tengo algunas notas que me parecen útiles cuando intentamos iniciar este proceso:

• Hazlo con colegas con los que te sientas cómodo y en confianza. Si no te sientes cómodo, va a ser muy difícil - ya que pueden haber preguntas que consideres “tontas”.
• Este es un proceso que debe ser natural. No considero que deba ser obligatorio y hacerlo obligatorio elimina el sentido de “colaboración”.
• No todo el código requiere realmente hacer programación en pareja. Iniciar una sesión para analizar una respuesta de un servidor sumamente enorme va a drenar a ambos ingenieros.
• Intenta hacer sesiones rápidas, concisas y al grano. Si crees que la sesión va a durar mucho, puedes separarla en mini-sesiones de 20 minutos máximo. Respeta el tiempo de los otros.
• Ten un listado de cosas que has intentado y hasta dónde llegaron tus investigaciones anteriores. Si puedes tener un listado de preguntas puntuales, es ideal.
• No tomes nada personal. Permanece abierto a comentarios, críticas y preguntas. Quizás el otro ingeniero no conozca el contexto tal como tú, pero tiene toda la intención de estar allí contigo.