Cuando empecé a trabajar a comienzos de los 2000 no había muchos recursos online para developers ni sysadmins. Los buscadores no eran muy buenos, no había muchos artículos de tecnología y por supuesto no existía StackOverflow ni tantos otros sitios del estilo. Cuando te encontrabas con un problema usando código de terceros, ya fuese una herramienta de sistemas o una librería para programar, era típico bloquearte durante horas o días. Si la herramienta era open source con una buena comunidad detrás podías intentar pedir ayuda en algún foro. Así aprendías a explicar cómo reproducir el problema e incluso a escribir test automáticos. Mi primera experiencia escribiendo un test fue cuando reporté un bug en el core de Mono, la versión libre de .Net. El equipo me respondió en el foro pidiéndome que adjuntase un test fallando que pusiera en evidencia el bug. Esto fue en 2005 o 2006. Yo no sabía lo que era un “test case”, así que gracias a mi pregunta en el foro me puse a mirarlo y pude añadir mi test. Ese fue mi verdadero comienzo en el interés por el testing, vino gracias a la comunidad open source.
Al bloquearte con mensajes de error de código de terceros, a menudo no te quedaba más remedio que abrir el código fuente y tratar de entenderlo para buscar la causa del error. Lo habitual es que estuvieras usando mal la librería o la herramienta, no tanto que hubiese un bug, y lo aprendías cuando leías el código fuente, porque te dabas cuenta de cómo el equipo de desarrollo esperaba que se usara. Leer código fuente open source era una práctica habitual para salir de los atascos. Los proyectos open source que tienen muchas personas contribuyendo suelen tener un código más cuidado que los de menor número de contribuciones. Así por ejemplo, el código de Firefox escrito en C++ está bastante cuidado en cuanto a que tiene funciones/métodos cortitos y se nota que se intenta que sea entendible - dentro de lo que cabe, teniendo en cuenta que no es cualquiera quien entiende C++. Una de las mejores formas de aprender a escribir código sostenible es leer código de proyectos que llevan muchos años usándose y evolucionando con éxito. Se aprende muchísimo viendo cómo están implementados los frameworks y librerías. Si usas Spring Boot, React, Angular, Symfony, o lo que sea, prueba a navegar por su código fuente y verás que aprendes muchas cosas sobre cómo está hecho. En su día yo aprendí mucho leyendo el código fuente de Mono y de CastleProject, aprendí sobre metaprogramación y arquitectura de software, entre otras cosas. También me resultó muy interesante ver el código de Linux o de Gtk. Creo que leyendo código open source he aprendido cosas que no hubiera sabido de otra forma; es una manera de aprender de developers de todo el planeta. Llegó un punto en que antes de elegir una librería, o un framework, me ponía a leerme su código fuente y sus test primero, así como el número de contribuciones que recibía y la proactividad de la comunidad en foros de ayuda.
Me he acordado de esto porque en estos días me puse a actualizar el Wordpress de mi sitio web y hubo un error. Los foros no me mostraban nada, era un error muy específico de mi versión al intentar ir a la nueva. No me quedó más remedio que abrir el código fuente php de un fichero y modificar una linea. No me llevó mucho tiempo y funcionó. ¿Cuánto tiempo hubiera estado haciendo búsquedas infructuosas por internet si no hubiera intetado resolver el problema por mi mismo? Lo peor es que no lo hubiera resuelto, me hubiera frustrado. Cuando los buscadores eran malos y no existía StackOverflow tuvimos que desarrollar mayor tolerancia a la frustración ante errores desconcertantes, así como creatividad o ingenio para resolverlos. Estoy contento de haber vivido ese momento histórico porque me ha beneficiado toda la vida; tras unos años trabajando de esta forma no hay problema técnico que me abrumase lo suficiente como para detenerme. Sé que con tiempo, investigación, ingenio, tenacidad, y pensando de maneras diferentes, se acaba sacando. Definitivamente, te recomiendo el ejercicio de navegar por el código fuente de tus proyectos o aplicaciones favoritas. Ganarás en habilidades técnicas, en capacidad de resolución de problemas e incluso aumentará tu tolerancia a la frustración cuando hay atascos.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista