Las herramientas que más te gustan son las que te están frenando

La mejor herramienta de programación no es la que te hace sentir hacker. Es la que olvidas que estás usando. Y eso contradice todo lo que la comunidad dev lleva años vendiéndote.

El creador de Odin —uno de los lenguajes systems programming más respetados del momento— publicó un ensayo que explotó en Hacker News con 384 puntos y 180 comentarios. Su argumento es devastador: mucha gente confunde "divertido" con "productivo", y las herramientas que más celebra son precisamente las que le cuestan más horas al día.

La trampa del "puzzle game"

Ginger Bill, el autor, le ha visto hacer esto a programadores durante años: tomar las deficiencias de una herramienta y venderlas como "un rompecabezas divertido de resolver". Construir un macro complejo para algo que en otro editor harías en un minuto con cursores múltiples. Pasar 20 minutos "hackeando" vim para hacer lo que Sublime hace con Ctrl+D — y luego presumirlo como si fuera una victoria.

El problema no es vim. No es emacs. No es ningún editor en particular. El problema es cuando dejas de notar que la herramienta te está costando tiempo y empiezas a creer que ese tiempo invertido es "aprendizaje".

¿Por qué defendemos lo que nos frustra?

Bill señala algo que duele admitir: la elección de una herramienta se convierte en una bandera tribal. Vim no es solo un editor — es una identidad. Emacs no es solo un IDE — es un estilo de vida. Y una vez que tu ego está invertido en una herramienta, admitir sus defectos se siente como admitir algo sobre ti mismo.

Esto explica por qué las discusiones sobre editores se vuelven religiosas. No se trata de productividad. Se trata de señalización tribal. Y la prueba es simple: si tu herramienta es realmente buena, ¿por qué necesitas convencer a los demás de que lo es?

La prueba del reloj que nadie quiere hacer

Aquí viene lo que nadie quiere escuchar: mide tu tiempo real. No cuánto te sentiste productivo, no cuánto te sentiste clever resolviendo un problema. El tiempo real de pared. Cuántos errores cometiste en el camino.

Bill dice que muchísimas herramientas "populares" perderían esa prueba. La sensación de inteligencia que viene de resolver un problema complicado no es lo mismo que productividad. Son dos cosas completamente distintas, y la mayoría de programadores las confunden todos los días.

Un dev que pasó 45 minutos configurando su terminal con el dotfile perfecto se siente productivo. Un dev que en 10 minutos ya estaba escribiendo código productivo es productivo. No es lo mismo.

La excusa de "alta configurabilidad"

Otro argumento favorito: "Pero es altamente configurable, ¡eso lo hace mejor!" Bill lo destroza: "Alta configurabilidad" muchas veces es solo una excusa para no tomar decisiones de diseño. El desarrollador se ahorra el trabajo de pensar en defaults buenos, y te carga a ti con la configuración.

Los buenos defaults son una forma de respeto por el tiempo del usuario. El creador hace el trabajo una vez para que mil usuarios no tengan que repetirlo. Las escape hatches están para los casos raros — no deberían ser un sustituto para hacer bien el caso común.

Linux desktop: el caso de estudio perfecto

Bill apunta al elefante en la sala: Linux sigue sin conquistar el escritorio en 2026 y una parte enorme del problema es cultural. Muchos usuarios de Linux disfrutan configurando archivos del sistema — es su idea de "divertido". Pasan horas personalizando su rice, su window manager, su tema de terminal.

Pero después de un tiempo, solo quieres que las cosas funcionen. La configuración máxima no debería ser el objetivo de una herramienta — debería ser una opción para cuando sea realmente necesaria.

¿Cuándo una herramienta es realmente buena?

La señal más clara de que una herramienta te está sirviendo: dejas de notarla. Se vuelve invisible. No celebras sus defectos porque no los estás convirtiendo en un hobby. No la defiendes porque nada de tu identidad depende de ella.

Usa vim, usa emacs, usa VS Code, usa lo que sea. Pero usa lo que desaparezca en el fondo y te deje trabajar. Esa es la única prueba que importa, y es completamente personal.

El veredicto

La mejor herramienta no es la que tiene la mejor historia. Es la que olvidas que estás usando.

Así que sí, disfruta tus herramientas por la alegría de programar. Pero se honesto sobre qué partes son genuinamente buenas y cuáles te has convencido de que te encantan. Tu productividad real — no la que te sientes, sino la que puedes medir — depende de eso.

Comparte esto con alguien que todavía cree que pasar 3 horas configurando dotfiles es "mejorar su flujo de trabajo". 🔥

¿Qué herramienta crees que es realmente "invisible" para ti? Cuéntanos en los comentarios — y si no puedes medirla en productividad real, tal vez no es tan buena como crees. 👇