perri.to: Un mejunje de cosas (by Horacio Duran)

Profesionalmente, si tuviera que resumirlo en una sola frase, diría esto:

Siempre elegí las herramientas que alguien estaba dispuesto a pagarme más para usar.

Todo empezó con Visual Basic 6.

En ese momento, al menos en mi país, era el lenguaje dominante para las aplicaciones de negocios. Estudios contables, empresas medianas, sistemas de gestión internos: todo corría sobre VB6. Me volví muy eficiente con él. No solo productivo: aprendí cómo funcionaba por debajo, sus límites, sus rarezas.

Con el tiempo, la gente empezó a llamarme para optimizar programas que habían crecido más allá de lo que podía manejar un “desarrollador de lógica de negocios” común.

¿Qué significaba eso?

Las aplicaciones empezaban chicas, crecían junto con el negocio y en algún momento chocaban con un muro de rendimiento. Visual Basic 6 no estaba exactamente diseñado para procesamiento pesado, pero en ese entonces las “cargas de trabajo grandes” no eran tan grandes como hoy. El hardware tenía limitaciones muy reales, y saber cómo exprimirle el rendimiento marcaba una diferencia.

Siempre fui curioso sobre cómo funcionan las herramientas a bajo nivel. Esa curiosidad me permitió optimizar código que había sido escrito con las reglas de negocio en mente, pero no necesariamente con el foco puesto en los modelos de memoria, los costos de ejecución o el comportamiento interno.

Claro, había alternativas como Java, usadas por empresas más grandes y equipos más formales. Pero yo me enfoqué en el nicho que tenía más sentido para mí profesionalmente. Y ese nicho era simple: donde muchos desarrolladores trabajaban, tarde o temprano aparecían los cuellos de botella de rendimiento. Ahí es donde yo entraba.

El salto a la web

Alrededor de 2003 o 2004, noté un cambio. Los desarrolladores que antes construían aplicaciones de escritorio en VB6 estaban migrando a PHP.

Hasta entonces, la web era mayormente un medio para publicar información. Pero después de la burbuja punto-com, algo empezó a cambiar: las aplicaciones empezaron a moverse del escritorio al navegador. Eran primitivas, pero claramente algo estaba pasando.

Así que aprendí PHP.

Y una vez más, hice lo que sabía hacer: optimizar, encontrar cuellos de botella, entender los límites del runtime. Las primeras versiones de PHP eran propensas a problemas de memoria, en parte porque estaban diseñadas para ciclos de ejecución de vida corta -renderizar una página y salir- no para procesos de larga duración o cargas de trabajo pesadas.

Eso me abrió un nicho similar al que tenía antes, pero en un dominio completamente distinto.

PHP explotó en popularidad. Irónicamente, eso fue lo que me hizo empezar a pensar: cuanto más mainstream se volvía, menos lugar habría para la especialización profunda. Los mercados saturados comprimen los márgenes.

Así que empecé a mirar hacia adelante otra vez.

Python y entender el lenguaje a fondo

A través de mi grupo local de usuarios de Linux, descubrí Python; creo que en ese momento era la versión 2.1.

Quedé fascinado.

Tenía rarezas interesantes, y pasé mucho tiempo refinando mi entendimiento de él. En algún punto de esos años, un amigo mío, Diego Sarmentero, arrancó un editor llamado Ninja IDE. Lo ayudé con él, y ese proyecto me obligó a entender de verdad muchos aspectos de bajo nivel de Python.

Python siempre me pareció interesante de una manera particular: el código académicamente más “correcto” no siempre era el más eficiente. Instanciar muchos objetos siguiendo estrictamente los paradigmas orientados a objetos podía ser elegante, pero bajo escenarios de alta contención (como endpoints REST muy usados), la presión de memoria puede volverse significativa.

Había mucho lugar para crecer con Python. El lenguaje estaba evolucionando rápidamente y se veía prometedor.

Pero entonces surgió otra oportunidad.

Canonical, Juju y el descubrimiento de Go

Entré a Canonical para trabajar en Juju, un sistema de orquestación en la nube que a la larga perdió la carrera contra Kubernetes (algunos argumentarían que ni siquiera estaban en la misma carrera).

Independientemente de ese resultado, ese período me presentó a Go.

Enseguida intuí que Go tenía algo especial en el espacio de la nube. Me especialicé todo lo que pude y pasé muchos años trabajando con él. Todavía hoy, cuando arranco un nuevo proyecto personal, Go suele ser mi elección por defecto, a menos que otra tecnología sea claramente más adecuada.

¿Suerte o patrón?

Profesionalmente, se podría decir que soy como un gato: tiendo a caer parado.

Quizás (y probablemente) sea más suerte que talento, pero de forma consistente me fui moviendo hacia herramientas que después se volvieron comercialmente viables. Aunque, pensándolo con más cuidado, quizás no estoy eligiendo lenguajes de programación.

Quizás estoy eligiendo la próxima herramienta que permite construir productos que alguien está dispuesto a comprar.

¿Y ahora?

Hoy, no creo que el próximo paso sea un lenguaje, ni siquiera un framework.

Es un LLM. O una combinación de herramientas asistidas por IA.

La pregunta ya no es “¿Qué lenguaje debería usar?”, sino más bien:

¿Qué combinación de herramientas me permite construir servicios viables, mantenibles y comercialmente relevantes?

El lenguaje se vuelve apenas un destino de compilación para las ideas.

Esta vez, mi nicho quizás esté en la experiencia arquitectónica. En saber qué pedirles que generen a estas herramientas. En guiarlas hacia algo que no solo funcione hoy sino que siga siendo mantenible mañana.

Quizás esta sea la vez en que me equivoco.

Pero solo hay una manera de averiguarlo.