3 mentiras que los programadores se creen sobre sus herramientas (y por qué pierden el tiempo)

Hay un momento incómodo en la vida de todo programador: cuando te das cuenta de que llevas 45 minutos configurando una macro en Vim para hacer algo que en Sublime Text resolverías con tres clics y dos segundos.

Pero no lo admites. Porque Vim mola. Porque te hace sentir hacker. Porque la identidad que construiste alrededor de tu editor de texto es más difícil de soltar que el código legacy de una startup de 2014.

Un artículo publicado esta semana en Hacker News (132 puntos, 94 comentarios en horas) expone esta verdad incómoda: los programadores han convertido las limitaciones de sus herramientas en un puzzle divertido, y están confundiendo sentirse productivos con ser productivos de verdad.

Estas son las 3 mentiras que te estás contando — y por qué te están costando horas de trabajo real.

Mentira #1: "Configurar mi herramienta es parte del oficio"

El autor del artículo, un ingeniero con 15 años de experiencia usando Sublime Text, señala algo incómodo: la gente celebra los defectos de sus herramientas como si fueran virtudes.

¿Has visto a alguien presumir de lo "divertido" que fue construir una macro en Vim para hacer un refactor de texto? El autor lo resume brutalmente: "Podría haberlo hecho en Sublime en un minuto con cursores múltiples, o simplemente escribiendo un script rápido".

La diferencia entre un herramienta buena y una moda es simple: una buena herramienta desaparece cuando trabajas. No te obliga a pensar en ella. No te pide que resuelvas acertijos. No te hace sentir inteligente por usarla — te hace eficiente.

Dato shockeante: El autor afirma que en 15 años solo ha "necesitado" una macro en Sublime dos veces. En ambos casos, escribir un script separado fue más rápido que configurar la macro.

Mentira #2: "Usar la terminal me hace más productivo que las GUI"

Aquí toca un nervio. La comunidad dev tiene una fijación casi religiosa con la terminal. "Las GUI son para principiantes", "TUI > GUI", "si no usas terminal no eres un verdadero programador".

El artículo lo desmonta con lógica simple: no hay nada inherentemente superior en una interfaz de texto. El problema es que la mayoría de las GUI están mal diseñadas y no se pueden navegar con teclado. Pero eso no es un defecto de las GUI — es un defecto de los desarrolladores que no las diseñaron bien.

Si pasas todo el día en la terminal, tiene sentido que uses herramientas de terminal. Pero la mayoría de los programadores no viven en la terminal. Saltan entre el navegador, Slack, Figma, el editor y la terminal. En ese contexto, una GUI bien diseñada con atajos de teclado te da cero fricción mental.

La pregunta no es "terminal vs GUI". La pregunta es: ¿tu herramienta te exige cambiar de contexto mental cada vez que la usas? Si la respuesta es sí, es una mala herramienta. Punto.

Mentira #3: "Mi editor es parte de mi identidad como programador"

Esta es la más peligrosa — y la más difícil de admitir.

El artículo lo explica mejor de lo que podría hacerlo yo: "Una vez que tu identidad está invertida en una herramienta, admitir sus defectos se siente como admitir algo sobre ti mismo".

Por eso las guerras de editores (Vim vs Emacs, VS Code vs JetBrains) son tan intensas. No se trata de productividad. Se trata de tribu. De pertenencia. De señalarle al mundo "mira, yo soy del tipo de programador que usa X".

El problema: cuando tu herramienta es tu identidad, dejas de evaluarla objetivamente. Defiendes sus缺陷 (defectos). Los celebras. Y lo peor: se los recomiendas a otros programadores junior que terminan perdiendo semanas de productividad por una herramienta que alguien vendió como "la única forma correcta de programar".

El test definitivo: tiempo real en la pared

El artículo propone una prueba brutalmente simple para saber si tu herramienta es realmente buena:

Mide cuánto tiempo real te tomó hacer algo, y cuántos errores cometiste en el proceso.

No cuentes lo "divertido" que fue. No cuentes lo "hacker" que te sentiste. No cuentes las 3 horas que pasaste configurando algo que "ahora vuela". Mide el tiempo en la pared y los errores. Nada más.

El autor desafía a cualquiera a pasar este test con las herramientas que evangelizan. La mayoría perdería.

Y ese es el punto: sentirse productivo no es lo mismo que ser productivo. La sensación de logro que obtienes al resolver un problema complejo con tu macro de 47 pasos no es productividad — es entretenimiento disfrazado de trabajo.

¿Entonces qué? ¿Dejo Vim y me paso a algo "aburrido"?

No. Ese no es el punto. Usa lo que te haga genuinamente productivo, no lo que te haga sentir bien sobre ti mismo.

Si Vim te funciona y completas tareas más rápido que con cualquier otra herramienta — perfecto, úsalo. Pero si pasas más tiempo configurando tu entorno que escribiendo código, tienes un problema y se llama procrastinación técnica con identidad incluida.

La mejor herramienta es la que menos notas. La que está ahí, funcionando, sin pedirte que la admires. Una buena herramienta es invisible.

Comparte esto con ese amigo que pasa 3 horas configurando su entorno y luego dice que "está programando".