El Blog de Figux

Tenía 14 años y estaba en el aula de informática, en el colegio donde estudié. En el grado noveno debías elegir un área de especialización: biología, matemáticas e informática, o comercio. Mi hermano mayor había elegido matemáticas e informática, y mis tíos, que habían pasado por el mismo colegio, biología. Ese día caluroso, en el aula de informática, el profesor nos enseñaba el famoso “Hola Mundo”. No recuerdo el lenguaje de programación, pero recuerdo perfectamente mi alegría al ver en la pantalla del computador:

“Hola Mundo”

No esperé la siguiente instrucción del profesor cuando cambié el string por “Hola Saúl” y funcionó. Me sentía el rey del mundo. No tenía nada que pensar: sería ingeniero de sistemas. La sensación de tener el control, de sentir que el computador hacía lo que yo le decía, era de felicidad absoluta.

Tres años después, en mi primer semestre de universidad, iba perdiendo “Fundamentos de Programación”. Todo se me hacía tan difícil —arreglos, variables, condicionales—  no sabía por qué, pero no entendía nada. Hasta que recordé ese día en el aula de informática del colegio. Fue como cuando Neo aprendió Kung Fu. Estuve a punto de perder la materia, pero logré sacarla adelante en el último corte. En esa época nos enseñaban C++. En los semestres posteriores aprenderíamos colas, filas, apuntadores (nos decían que era súper peligroso porque ingresábamos directamente a la memoria del computador), listas y funciones recursivas. En primer semestre nos dijeron que la recursividad era lo peor del mundo, que mal diseñada se podía comer toda la RAM; en algoritmia nos dijeron que era lo mejor del mundo. Nos hacían entrar a páginas de problemas y resolverlos, y en esa época no solo importaba que funcionara: tenía que ser rápido y consumir poca RAM. Esas páginas de ranking evaluaban el código y lo calificaban; competías con “programadores” de todo el mundo.

Llegó el mundo Linux. Todo era tan complejo al principio —los drivers no existían como en Windows, los juegos no existían como en Windows— y aun así era feliz creando particiones en el disco duro para tener booteando Windows y Linux juntos. Otra vez el peligro de dañar las cosas, el ponerle overclocking a la CPU: teníamos el control de todo y eso nos hacía sentir poderosos. Con Linux llegaría el odio a Windows y a todo lo privativo. Soñaba con ser alguien grande, con desarrollar una aplicación que llegara a todos, con ser colaborador del kernel de Linux.

El poder y el código espagueti

Como todos en la carrera, arreglábamos computadores de vez en cuando —entiéndase como formatear o hacer mantenimiento: desfragmentar, pasar el antivirus, ejecutar otras herramientas, limpiar el registro de arranque y esas cosas. Eran tiempos donde se pirateaba Windows, programas y juegos. Entré en foros y listas de correos de crackers, a buscar ese “if” donde se validaba el serial de la licencia y a saltarlo con assembler. No me duró mucho la etapa de cracker; eran los inicios de internet y ya había información por todas partes. Mi primera gran idea fue desarrollar una imagen de Windows que se autoinstalara; descubrí que alguien ya lo había hecho, una versión de Windows desatendida y sin algunos programas, y de inmediato se volvió la preferida mía y de mis amigos. Luego quise crear un instalador con todas las cosas que usaba para el mantenimiento, pero no sabía cómo, y el proyecto nunca lo saqué adelante. Seguíamos programando en C++, haciendo aplicaciones para Windows, cuando de repente llegó Java. Prometía crear ejecutables tanto para Windows como para Linux, hasta para lavadoras; su programación era “empresarial” y más ordenada, pero al mismo tiempo más compleja. Duró poco mi aprendizaje en Java, cuando conocí PHP: un cambio del cielo a la tierra. Para hacer un “Hola Mundo” en Java debías crear cuatro clases; en PHP mezclabas HTML, PHP y hasta JS. Un gran poder conlleva una gran responsabilidad: odiado por muchos, querido por otros, ese código espagueti inundó la web.

Gmail acababa de estrenar su chat, y AJAX salía al mundo con jQuery. Diseñé mi primer framework, uno con login y un scaffold influido por Ruby on Rails; crear módulos CRUD era sencillo, la vista de editar y crear se reutilizaba, y todas las peticiones se hacían por JS. Sin saberlo, estaba creando SPA (Single Page Applications); años después un amigo me enseñaría Angular y entendí que era el mismo principio. Me interesé en los frameworks de PHP, y aunque nunca los usé, mis favoritos eran Cumbia y Falcon PHP. Poco a poco fui investigando; quería que mi framework creciera y fuera popular. Yo era un puritano del rendimiento y criticaba que los frameworks tenían muchas cosas que uno no usaba y que no sabía cómo funcionaban, eran cajas negras para mí. Así que quise hacer un framework ligero que fuera muy rápido. Después de investigar y darle prioridad a la seguridad, descubrí cómo funcionaban los otros frameworks, y ante la imposibilidad de sacar adelante el mi propio framework, abandoné el proyecto y me pasé a Laravel. En esa época, Zend —la empresa a cargo de PHP— tenía su propio framework, pero era una locura, me recordaba a Java, y Laravel era el framework “para artesanos”, así nos gustaba llamarnos: le daba valor a nuestro “trabajo”.

La guerra de los frameworks

El tiempo siguió evolucionando hacia la web. El boom de JS comenzó con Node y Express, luego llegó Mongo, y todo el stack LAMP (Linux, Apache, MySQL, PHP) pasó a ser MEAN (Mongo, Express, Angular, Node). Me resistí al cambio inicialmente, no quería abandonar PHP, pero un amigo me enseñó que en nuestro ámbito no es bueno casarse con ninguna tecnología, cosa que le agradezco hasta el día de hoy. Comenzó la batalla de los frameworks de JS —Angular, Vue, React— y era cosa de locos, como ahora con la IA: cada tres meses salía un framework nuevo, una actualización. Lo más loco ocurrió cuando Angular pasó de su versión 2 a la versión 5: cambiaron absolutamente todo, el código era cero compatible, tocaba reescribirlo todo a la versión 5. Odiaba sobremanera el “npm install” y la cantidad de librerías que nos facilitaban la vida, pero que hacían que el proyecto fuera extremadamente pesado y, a mi modo de ver, ineficiente. Pero eran otros tiempos: el problema ya no era la RAM, los “programas” se ejecutaban en el navegador, no había peligro de dañar el computador, el navegador hacía de sandbox manteniendo todo seguro. El hardware aumentó muchísimo y ya nadie se preocupaba por el rendimiento.

En mi trabajo tuve retos para mejorar la velocidad de la aplicación. Hice un par de refactorings que, a mi modo de ver, mejorarían la app en mínimo el doble; me sentía casi orgulloso de antemano, pensaba ponerlo de ejemplo ante los demás programadores. Cuando vimos los resultados, el software solo respondió unos 300 milisegundos mejor. Al principio fue frustración pura. Después vino la resignación, y con ella un aprendizaje: no tenía que pelear contra el framework, podía actualizarlo y aprovechar sus nuevas funcionalidades; tocaba ser práctico. Entendí que era una guerra perdida —en vez de gastar dos semanas en esos refactorings, era mejor poner un servidor más grande, y los resultados eran similares—, y entendí también que yo ya no era solo un desarrollador peleando por su código: era el líder de desarrollo, el que ponía las pautas de cómo se creaba y se mantenía el código de otros.

El artesano contra el ingeniero

Aparecieron los bootcamps. Ya no era necesaria una carrera de cinco años para programar; con solo seis meses salían personas capacitadas y con mejores herramientas. En el trabajo contratamos a uno recién salido, sin experiencia pero muy bueno. Me enseñó cosas sobre Visual Studio Code, y bien guiado era un buen recurso. Su debilidad, al igual que la de todos cuando salimos, era la perfección: quería el mejor algoritmo y se demoraba mucho, muchas veces haciendo sobreingeniería a problemas sencillos.

Poco a poco los nuevos programadores hacían menos código: encontraban una librería que solucionara todo y simplemente la instalaban. Muchas veces esas librerías hacían muchas cosas más y pesaban mucho, pero el problema se solucionaba. “No mates una mosca con un cañón”, creo que esa frase nunca la oyeron. Se fue al diablo, poco a poco, eso de ser “artesanos” del código. Quise retomar las buenas prácticas, leyendo sobre guías de codificación. En el trabajo, por fin pudimos separar el frontend del backend. ¿Cómo lo hicimos? Saliendo de PHP: nuestro lenguaje de frontend fue Angular y nuestro lenguaje de backend, Golang. Hicimos aplicaciones interesantes para la empresa, diseñamos un ecosistema complejo de “microservicios”, hicimos cosas muy buenas.

Ahí tuve otro dilema con el performance, esta vez con la arquitectura hexagonal y su montón de archivos y funciones separadas. No podemos negar que llamar tres funciones de forma secuencial es más lento que tener solo una. Pero de a poco fui haciendo acuerdos conmigo mismo: sigo tan obsesionado con el rendimiento como siempre, pero ahora primero pienso que funcione, y después hacemos el refactoring. Ya no pienso tanto en el performance puro; pienso más en la calidad del software, en que tenga buenas prácticas y sea fácil de leer. Si el código está bien hecho, puedo sacrificar un poco de latencia a cambio. Creo que esa es la enseñanza más grande de todos estos años: no quedarme estático, aunque no esté de acuerdo con el cambio.

La máquina que programa

Llegó la IA, y Copilot empezó pegando duro. Una de las personas con las que trabajaba comenzó a pagar la suscripción, y se veía cómo mejoraba su productividad. Yo tenía mis dudas, pero cuando lo probé junto con Q de AWS, comprobé yo mismo que, bien guiada, era una buena herramienta: completaba código de forma óptima, claro está, cosas pequeñas como un loop o una función bien descrita.

Hicieron su entrada los LLM, y murió un grande: Stack Overflow. Claro que más de una vez me salvó el culo, pero era mucho más fácil decirle a la IA que algo no funcionó y darle el error para intentarlo de nuevo, que buscar entre las respuestas de Stack Overflow. Ahora estamos “programando” con agentes. Sin ir tan lejos, en la empresa donde trabajaba, una de las personas que no hace parte de los desarrolladores es quien más módulos saca a producción; es el orgullo del área de IA y la vergüenza del área de tecnología. Una vez más, la lección es no casarnos con ninguna tecnología: debemos aprender y fluir con las tendencias. A algunos negocios no le importa la calidad del código que está en producción, le importa que solo fueron cuatro horas creándolo y que, obviamente, funciona.

Me siento un poco como cuando pasamos de las aplicaciones de escritorio a la web con PHP: mucha gente aprendió PHP sin saber programar, y por eso se veían cosas de tan mala calidad, pero la web se inundó de páginas —creo que hasta hoy sigue siendo el lenguaje con más páginas en internet—. Creo que lo mismo pasará con la IA: es una herramienta al alcance de todos, la web se va a inundar de proyectos, y la gente ni siquiera va a saber distinguir si están hechos con IA o no, si están bien hechos o no. Pero eso no será el problema real, porque la IA en manos de un buen desarrollador va a ser un buen producto. Lo que sí no puedo negar es que me da un poco de rabia que todo el esfuerzo de estos años se vea resumido en pocas horas, aunque sé que esa misma IA se alimenta del código y los textos que gente como yo escribió antes.

Neo

Hace poco regresaba de un viaje en avión y puse Matrix. Todo este artículo nace de esa película, tal vez sean los cuarenta que me respiran en la nuca, o el haber vivido la evolución de todo. Volví a ver a Neo aprendiendo Kung Fu en segundos, el mismo hacker que quería ser yo aquel día del “Hola Mundo”, ahora siento envidia por la nueva generación salarios bien pagados, la IA trabajando para ellos, el sueño de todo pensionado.