El día que decidí ser un mejor desarrollador

Alguna vez leí una frase de Sam Redwine en un artículo en internet mientras todavía estaba en la Universidad y que me se me quedó grabada en la mente.

Software and cathedrals are much the same — first we build them, then we pray.

La mayoría de proyectos que desarrollé en la Universidad venían de la mano de muchos prints, dumps y logs para debuggear, de prosas de código gigantes, de lógica repetida en varios lugares, de cosas que funcionaban y no sabía por qué y de cosas que no funcionaban y tampoco sabía por qué. Solía rezar de vez en cuando por las catedrales que programaba; Si bien en la Universidad nos enseñaban las bases para programar, estoy seguro que no nos enseñaban las buenas prácticas de un programador integral y que yo tampoco hice un gran esfuerzo por aprenderlas de manera autodidacta.

Ahora con un par de años de experiencia, doy fe de que las buenas prácticas siempre son difíciles de aprender. Si fueran fáciles todos seríamos artesanos de nuestros oficios.

Soy bueno indentando de manera de correcta. Gracias a Dios uso nombre de variables medianamente expresivos, y vaya sí los desarrolladores sabemos lo difícil que resulta nombrar bien las cosas. Cumplo bastante bien con los deadlines. Sé lo necesario para desarrollar aplicaciones usando tecnologías trendy. Mis decisiones de arquitectura no resultan ser tan malas. Intento optimizar los algoritmos que escribo. Intento escribir código legible. Declaro funciones expresivas. Y así. Pero dentro de mis estándares soy un desarrollador promedio.

Si soy honesto como ustedes, cada tanto recuerdo las palabras de Sam porque me imagino Sagradas Familias y tengo esta constante sensación de no terminar de construírlas, cada tanto me pongo a rezar porque nunca estoy lo suficientemente seguro de haber hecho de la mejor manera las cosas que hago. Y si vuelvo a ser honesto, a veces siento que soy muy bueno siendo silenciosamente mediocre. Aunque parezca que estoy siendo demasiado duro conmigo mismo, no es así. Para mejorar hay que dejar de lado la autocomplacencia. ¿Cuándo fue la última vez que hicieron algo solamente bien y los felicitaron amenamente como si hubiesen hecho algo realmente extraordinario?

El día que decidí ser un mejor desarrollador supe que tenía que creer que la lista de cosas que supongo hacer bien, las podría hacer mejor, y que lo que no hago y comience a hacer, por pequeño que parezca, me hace avanzar un paso más para llegar a ser el desarrollador que quiero ser.

Atrás quiero que queden los días en los que no aplicaba TDD a cada una de las aplicaciones que escribo. Los días en los que no podía responderme a mí mismo de manera técnica porqué no usar un approach contra otro. Los días en los que sentía miedo de mostrar mi código a desarrolladores que respeto. Los días en los que no me tomaba el tiempo para refactorizar el código que escribo. Los días en los que no leía literatura o artículos académicos. Los días en los que no tenía proyectos personales. Los días en los que no me apasionaba por hacer de manera correcta el oficio que elegí.

Hay un dicho danés que cita de la siguiente manera:

La honestidad en las cosas pequeñas no es una cosa pequeña.

Y juzgarme de manera tan honesta no ha sido una tarea fácil ni pequeña. Pero dado que Dios está en los detalles y los detalles son casi siempre tan sutiles y pequeños que solo los artesanos saben dónde ponerlos de manera natural, estoy seguro que he comenzado a ver el camino correcto para convertirme en el desarrollador que quiero ser.

Espero ir contando de a poco, las cosas con las que me topo en este camino.