El día que mi editor de código dijo basta
Hola a todos. ¿Alguna vez habéis sentido que vuestro editor de código parece más un cuadro de mandos de la NASA que una herramienta sencilla para escribir texto? A mí me pasó hace un par de meses. Abría VS Code y, antes siquiera de poder escribir la primera línea de una función, empezaban a saltar pop-ups, iconos de colores, sugerencias intrusivas y una barra de estado que parecía un árbol de Navidad. Estaba tan obsesionado con tener el "setup perfecto" que acabé convirtiendo mi herramienta de trabajo en una distracción constante.
Mi experiencia con la acumulación digital
Durante años, cada vez que veía un vídeo en YouTube de "Las 10 extensiones imprescindibles para desarrolladores en 2024", iba directo al marketplace y las instalaba todas. Que si un linter para CSS que nunca usaba, que si un decorador de pestañas de colores, que si tres extensiones distintas para autocompletar etiquetas HTML... La lista era interminable. Llegué a tener más de 45 extensiones activas. La consecuencia directa no fue que programara mejor, sino que mi editor tardaba una eternidad en arrancar y, lo peor de todo, mi RAM sufría innecesariamente.
La gota que colmó el vaso fue un conflicto extraño entre dos extensiones de formateo que me rompió el código de un cliente justo antes de un commit importante. En ese momento me di cuenta de que no sabía ni qué herramienta estaba haciendo qué. Me sentí un extraño en mi propia casa. Así que, en un arrebato de minimalismo, hice lo impensable: Disable all extensions. Y, poco a poco, fui desinstalando casi todo.
¿Por qué me parece importante simplificar?
La verdad es que nos venden la idea de que más herramientas equivalen a más productividad, pero en mi caso fue todo lo contrario. Al limpiar el ruido visual, mi cerebro empezó a centrarse más en la lógica del código y menos en los colorines del editor. Me di cuenta de que muchas de las cosas para las que usaba extensiones ya vienen integradas de forma nativa en VS Code hoy en día. Por ejemplo, el Bracket Pair Colorizer ya es nativo, el Auto Rename Tag también tiene su versión integrada, y muchas de las ayudas de tipado ya las gestiona de maravilla el propio motor de TypeScript.
Trabajar con lo básico me obligó a aprenderme los atajos de teclado reales del editor, en lugar de depender de una extensión que lo hiciera por mí. Hay algo muy satisfactorio en dominar tu herramienta sin necesidad de muletas externas. Además, la velocidad... ¡vaya tela con la velocidad! El editor vuela. Los archivos se abren al instante y la búsqueda global no se queda colgada pensando.
Lo que ha sobrevivido a la quema
No os voy a mentir, no me he quedado a cero. Hay cosas que son fundamentales para mi flujo de trabajo diario como desarrollador web. Después de un par de semanas probando qué echaba de menos de verdad, este es mi equipo titular:
1. Prettier y ESLint: Estos son innegociables. Mantener el código limpio y con un estándar es vital, sobre todo cuando trabajas en equipo. No quiero pensar en espacios o tabuladores, quiero que el editor se encargue al guardar.
2. GitLens (en su versión ultra reducida): Solo lo uso para el current line blame. Me ayuda a saber quién (probablemente yo mismo hace seis meses) escribió esa línea de código tan cuestionable.
3. Tailwind CSS IntelliSense: Si trabajas con Tailwind, esto es salud mental pura. Recordar todos los nombres de las clases es imposible.
4. Theme y File Icons: Uso un tema oscuro sencillo (actualmente uno basado en Tokyo Night) y unos iconos que no me distraigan demasiado. El aspecto estético también importa para estar cómodo.
Para todo lo demás, uso la terminal integrada o simplemente confío en mi capacidad para escribir código sin que una IA o un plugin me susurre al oído constantemente qué es lo que cree que quiero hacer. Por cierto, con el tema de la IA, he pasado de tener tres extensiones a usar solo una cuando realmente necesito ayuda con un boilerplate pesado.
Cómo trabajo ahora y qué he aprendido
Mi flujo de trabajo actual es mucho más consciente. He descubierto que menos es más. Ahora, si necesito una funcionalidad específica para un proyecto puntual (por ejemplo, algo de Docker o una base de datos específica), instalo la extensión, la uso y, en cuanto termino esa fase del proyecto, la desinstalo o la desactivo. No dejo que se quede ahí "por si acaso".
He aprendido que el setup perfecto no es el que tiene más plugins, sino el que te permite entrar en estado de flow más rápido. El ruido visual es el enemigo número uno de la concentración. Si tu editor te está gritando con subrayados rojos, amarillos y azules cada vez que dejas una frase a medias, es muy difícil mantener el hilo de la lógica compleja.
Reflexiones finales
Si sientes que tu flujo de trabajo está algo pesado, te animo a que hagas el experimento. No hace falta que borres todo de golpe como hice yo, pero prueba a desactivar esas extensiones que no has usado en la última semana. Te sorprenderá ver cuántas de ellas eran simplemente "ruido de fondo". Al final del día, lo que importa es el código que entregamos y lo cómodos que nos sentimos escribiéndolo, no lo bonito que luzca nuestro panel de extensiones en una captura de pantalla para Twitter.
¿Y vosotros? ¿Sois de los que tienen cien extensiones o preferís el estilo minimalista? Me encantaría saber vuestra opinión, porque al final, cada desarrollador es un mundo y lo que a mí me da paz mental, a otro le puede parecer un desierto aburrido. ¡Nos leemos en la próxima!