Reinventar la rueda tiene más sentido del que parece

Hay un tipo de culpa silenciosa que muchos programadores conocen bien: llevas horas construyendo algo y de repente te asalta la duda de si no existirá ya una solución de hace décadas, infinitamente más robusta, que simplemente no conoces todavía. ¿Estás perdiendo el tiempo? Andrew Quinn, en un artículo técnico sobre cómo sustituyó una base de datos SQLite de 3 GB por un binario FST de 7 MB, dedica una nota al pie a desmontar esa culpa. Simon Willison la rescató en su blog el pasado 10 de mayo en una entrada de citas breves que, en este caso, vale mucho más que su extensión.

La trampa del conocimiento previo

El argumento de Quinn es directo: la parálisis ante lo que ya existe es una trampa. No hace falta reinventar mil ruedas, pero tampoco cero. Su estimación, expresada con honestidad intelectual poco habitual, es que entre cuatro y cinco reimplementaciones en la mayoría de dominios son suficientes para llegar al verdadero límite de lo que se sabe sobre un problema. En campos más rigurosos —matemáticas o informática teórica, por ejemplo— ese número puede acercarse a veinte o treinta.

La lógica subyacente no es romantizar el esfuerzo inútil. Es que cada vez que construyes algo desde cero, aunque ya exista, formulas preguntas dirigidas que ningún tutorial formula por ti. Aprendes qué decisiones de diseño se tomaron y por qué, qué compromisos implica cada elección, dónde están los límites reales del enfoque. Leer documentación de `awk` te enseña qué hace `awk`; escribir tu propio procesador de texto columnar te enseña por qué `awk` es como es.

Por qué importa esto ahora

Esta reflexión llega en un momento en que la pregunta «¿para qué construir algo que ya existe?» se ha vuelto más intensa que nunca. Con asistentes de código como Claude integrados en flujos de trabajo diarios, la capacidad de obtener una implementación funcional de casi cualquier cosa en segundos ha bajado el coste marginal de tener código casi a cero. Pero eso no cambia el coste de entender ese código, ni la utilidad de haber pasado por el proceso de construirlo.

Lo que Quinn describe no es nostalgia artesanal ni una crítica velada a las herramientas modernas. Es una observación sobre epistemología práctica: el camino más rápido hacia la frontera real del conocimiento en un dominio no es la acumulación pasiva de soluciones ajenas, sino la combinación de reimplementación selectiva con preguntas bien dirigidas. El ratio entre ambas cosas es el argumento central.

Para quién es relevante

Esta perspectiva resulta especialmente útil para tres perfiles:

• Desarrolladores junior que sienten que nunca saben suficiente antes de empezar. La respuesta no es estudiar más antes de construir; es construir para estudiar mejor.
• Equipos que forman a nuevos miembros y dudan entre asignar tareas reales desde el primer día o priorizar formación estructurada. Quinn sugiere que el aprendizaje más eficaz ocurre en la fricción de resolver problemas concretos, no en la contemplación de soluciones ya resueltas.
• Cualquiera que use asistentes de IA para programar y note que genera código que funciona pero no comprende del todo. La herramienta no elimina la necesidad de reinventar algunas ruedas; simplemente cambia cuáles merece la pena reinventar.

El artículo técnico original de Quinn —sobre FSTs como alternativa de almacenamiento— es interesante por sí mismo como ejercicio de optimización. Pero la nota al pie puede ser lo más valioso del texto para cualquiera que lleve poco tiempo en este oficio, o para quienes llevan mucho y han olvidado por qué empezaron a construir cosas.

---

Desde EP, compartimos la idea central: la culpa por reinventar la rueda suele ser menos productiva que la rueda misma. Que Simon Willison la haya considerado digna de destacar, con todo lo que lee a diario, ya es una recomendación bastante fiable.