La satisfacción de lo pequeño
Feb. 06, 2026
Hace poco escribí una librería y línea de comandos para obtener datos de NewsAPI.org, en Nim. Menos de 1000 líneas, sin dependencias externas. Y me di cuenta de algo: reafirmé lo bien que se siente trabajar en un proyecto así de pequeño. En mi día a día, entre ciencia de datos y desarrollo de sistemas, es todo pipelines complejos, dependencias pesadas, infraestructura distribuida. Pero con este proyecto pude mantener literalmente todo en la cabeza. Cada decisión tenía consecuencias que podía predecir. Los cambios no disparaban cascadas impredecibles. Me hizo reflexionar en cómo el tamaño afecta la relación que tenemos con nuestro proyectos.
Lo que más me sedujo: en proyectos pequeños, la claridad simplemente sucede. No es algo por lo que tengas que luchar—es el estado natural. Contrasta fuerte con los sistemas de datos que integró normalmente, donde muchas dependencias y herramientas de orquestación son inevitables. Aquí, el sistema de tipos de Nim me dejó expresar las cosas directamente: enumeraciones para categorías de noticias, estructuras que mapean uno a uno con los parámetros de la API. Sin capas de más. Todo el código relevante en pocos archivos, nada de magia oculta, nada de dependencias que actualizar, ningún framework nuevo que aprender. Aunque no conozcas de programación, si le das un vistazo entiendes este código. Esa transparencia total es rara en proyectos grandes, especialmente en el mundo de data science.
Para el README.md fui con el estilo clásico de las páginas man de Unix. Esa estructura de siempre: NAME, SYNOPSIS, DESCRIPTION, OPTIONS, EXAMPLES. Me gusta porque refleja cómo realmente busco información cuando necesito algo. Nada de querer enseñar o filosofar—solo describir qué hace el software, con precisión pero sin complicaciones. Cada función responde tres preguntas básicas: qué hace, qué necesita, qué devuelve.
Algo que realmente disfruté: la ausencia de tentaciones. Es mucho más fácil resistir el "solo una característica más" cuando el proyecto es pequeño. O usar alguna librería sofisticada cuando en realidad bastan diez líneas. O abstraer antes de tiempo. Cada línea está ahí por algo específico. Las pruebas funcionan como especificación ejecutable—es documentación que nunca queda obsoleta. Esa disciplina simplemente emerge cuando el proyecto cabe en tu cabeza.
Este proyecto me dejó claro que el tamaño importa más de lo que admitimos. En sistemas de datos la complejidad muchas veces viene con el territorio—datos distribuidos, procesamiento paralelo, modelos estadísticos complejos. Pero en herramientas e infraestructura, ¿cuánta de esa complejidad realmente necesitamos? En proyectos grandes siempre estamos peleando con la complejidad acumulativa. Cada framework tiene sentido. Cada dependencia está justificada. Cada capa de abstracción resuelve algo. Pero al final terminamos con un sistema más complejo que el problema que queríamos resolver. En un proyecto pequeño esas fuerzas no tienen oportunidad de acumularse. Veo todo el código, entiendo las decisiones, predigo las consecuencias.
No digo que esto sea la respuesta para todo. Obviamente hay problemas que necesitan sistemas complejos. Pero sí creo que estamos perdiendo algo importante: la satisfacción de entender por completo en lo que estamos trabajando. La confianza de hacer cambios sin miedo. Saber que va a funcionar dentro de años sin cambiarle nada. Cuando logras hacer algo que cabe en tu mente, desarrollar se siente completamente diferente. Y eso vale la pena preservarlo, especialmente los que trabajamos entre varios mundos.
Recursos:
Note: Este artículo cuenta con una traducción al inglés.