Estrés, cansancio, problemas externos… todo programador debe luchar con errores o fallas en su código, y hay razones de sobra para que el debugging se convierta en una pesadilla. Sin embargo, existe una técnica muy curiosa que se remonta a fines de los ’90, e involucra a un patito de goma. ¿Cuál es la idea exacta? Que el programador se vea obligado a explicar al pato una línea a la vez de su código, y a través de ese proceso de deconstrucción, encontrar la solución.
La historia de hoy se remonta a 1999, año en el que Andrew Hunt y David Thomas escribieron The Pragmatic Programmer, un libro para programadores que rápidamente se convirtió en texto universitario. Con la ayuda de cuentos cortos y otros trucos, Hunt y Thomas entregan al potencial programador herramientas destinadas a optimizar su proceso de desarrollo, comenzando por la necesidad de ser un «early adopter», adaptarse a gran velocidad, nunca perder el pensamiento crítico ni el realismo, y funcionar como un comodín.
Lamentablemente, no es un título del todo accesible que digamos. Su última edición no baja de los 45 euros (a menos que busquemos su versión digital), y si la memoria no me falla, jamás fue traducido al español. Pero hay un pequeño detalle en ese libro que se ubicó por encima del resto en tiempo récord, y sobre el que muchos programadores juran.
La clave es colocar un patito de goma en el escritorio. Cuando el programador no logra encontrar un error o se queda «trabado» en cierto punto, el patito se transforma en una especie de oyente y estudiante pasivo. El desarrollador procede a explicar el problema paso por paso, y a través de esa misma explicación, encuentra la solución. Esto es bastante común entre colegas y compañeros de trabajo (o programadores hablando a sus mascotas), pero el patito carga con dos ventajas importantes: No interrumpe, y evita que molestemos a alguien más.
Lo más valioso es que obliga al programador al comenzar desde el principio, y al avanzar no hace más que «reanalizar» el código en su mente. Esa visualización actualizada de su proyecto suele aportar la claridad suficiente para detectar el problema, a un punto tal que en ocasiones sólo necesita describir uno o dos detalles del inconveniente. Parece una broma, pero no lo es. Mientras que algunas tareas requieren un enfoque total, otras necesitan ser «desarmadas» de algún modo, aún cuando la única audiencia es un patito de goma.
