El código que no escribí

El commit del que más orgulloso estoy este año no añade absolutamente nada. Son doscientas y pico líneas en rojo, un archivo menos en la carpeta y una web que sigue funcionando exactamente igual que antes. Bueno, igual no: un poco más rápida, un poco más ligera y sin un plugin que llevaba dos años sin recibir una actualización y al que ya solo mantenía vivo mi mala conciencia.

Nadie te aplaude por eso. En este oficio se mide por lo que se añade: funcionalidades nuevas, integraciones, paneles de opciones, cosas que se mueven al hacer scroll. El trabajo de quitar es invisible por definición, porque su resultado es que no pasa nada. Y sin embargo llevo unos cuantos años convencido de que la mejor línea de código que he escrito es, muy a menudo, la que finalmente no hizo falta escribir.

El diff en rojo también es trabajo

Existe una fantasía muy extendida según la cual programar consiste en producir. Escribes, se acumula, el proyecto crece, el repositorio engorda y esa gráfica ascendente te dice que vas bien. Es una métrica cómoda porque se cuenta sola. El problema es que mide el volumen, no el valor, igual que medir un libro por el número de páginas o un viaje por el número de sellos en el pasaporte.

Cuando abro un proyecto heredado —y en quince años he abierto unos cuantos— lo primero que hago ya no es preguntarme qué le falta, sino qué le sobra. Casi siempre sobra bastante: una librería para hacer un cálculo de fechas que hoy resuelve el navegador, un slider para tres imágenes que nadie mira, un sistema de pestañas de cuarenta kilobytes para ocultar dos párrafos de texto. Todo eso tuvo su momento y su motivo. Lo que pasa es que el motivo caducó y el código se quedó.

Borrar da miedo, eso es cierto. Da miedo porque no sabes qué se rompe, y no lo sabes porque nadie documentó por qué estaba ahí. Pero ese miedo es precisamente el síntoma: si no te atreves a tocar tu propio proyecto, el proyecto ya no es tuyo del todo.

Cada dependencia es una hipoteca

Instalar una dependencia se parece muchísimo a firmar algo sin leer la letra pequeña. Tardas cuatro segundos, resuelves el problema de esta tarde y adquieres, sin darte cuenta, un compromiso a diez años con alguien a quien no conoces y que no te debe absolutamente nada. Puede que mantenga el paquete durante una década. Puede que lo abandone en marzo. Puede que lo venda. Puede que meta un cambio incompatible en la próxima versión menor porque le apeteció.

El coste real de una dependencia no está en el día que la instalas, sino en todos los días siguientes: las actualizaciones, los avisos de seguridad, la incompatibilidad con la versión nueva de otra cosa, el build que un día deja de funcionar sin que hayas tocado nada. Multiplícalo por la cartera de sitios que mantienes y ya no estamos hablando de una decisión técnica, sino de cuántos sábados vas a dedicar a apagar fuegos que encendiste tú mismo.

Viajo casi siempre con equipaje de mano, y no por deportividad ni por ahorrarme veinte euros. Es que llevar poco cambia la relación con el sitio al que vas: no hay cinta de equipajes, no hay maleta perdida en Ámsterdam, no hay arrastrar ruedas por una calle empedrada a las once de la noche. Un proyecto con pocas dependencias funciona igual. Te mueves más rápido, y sobre todo puedes volver a él dentro de tres años sin que se haya convertido en un yacimiento arqueológico.

El HTML lleva años haciéndote el trabajo

Un porcentaje generoso del JavaScript que se escribe hoy existe para replicar cosas que el navegador ya sabe hacer de serie. Los acordeones se hacen con details y summary. Las ventanas modales tienen su elemento propio, dialog, con foco atrapado y tecla de escape incluidos. La carga diferida de imágenes es un atributo, loading="lazy". Los campos de fecha, de color, de rango o de búsqueda vienen con su interfaz nativa, su teclado adecuado en el móvil y su comportamiento esperado.

La validación de formularios es el caso más flagrante. required, type="email", pattern, min, max: el navegador valida, avisa, traduce el mensaje al idioma del usuario y lo anuncia al lector de pantalla. Y aun así seguimos viendo formularios de contacto con doscientas líneas de validación propia que hacen lo mismo, peor, y solo en castellano.

Y luego está el asunto de la accesibilidad, que es donde la cuenta sale realmente cara. Un button de verdad recibe el foco, responde a la barra espaciadora, se anuncia como botón y funciona con el teclado sin que hagas nada. Un div con un onclick no hace nada de eso hasta que te lo curras a mano, y casi nadie se lo curra a mano. Elegir el elemento correcto no es purismo: es que te regalan media hora de trabajo bien hecho a cambio de escribir cinco letras en lugar de tres.

CSS creció mientras mirábamos a otro lado

Mi generación de desarrolladores aprendió que CSS servía para poner colores y que lo serio se hacía con JavaScript. Esa idea sigue instalada en mucha gente que no ha vuelto a mirar la especificación desde entonces, y mientras tanto CSS se ha comido media docena de librerías enteras sin hacer ruido.

Los layouts de rejilla ya no necesitan un framework de doce columnas: grid hace en cuatro líneas lo que antes eran mil de un archivo que nadie leía. Las tipografías fluidas se resuelven con clamp() en lugar de con un script que escucha el redimensionado. Los carruseles decentes salen con scroll-snap. Las cabeceras pegajosas son position: sticky. Las proporciones de imagen, aspect-ratio. Y :has() permite algo que durante veinte años fue el chiste recurrente de la profesión: estilar un elemento en función de lo que contiene, es decir, reaccionar sin JavaScript a que un campo esté relleno o a que una tarjeta tenga imagen.

Las consultas de contenedor rematan la faena. Durante años los componentes tenían que adivinar dónde estaban mirando el ancho de la ventana, que es como decidir cómo vestirte consultando el tiempo de la provincia entera. Ahora un componente se adapta al espacio que realmente ocupa. Es más simple, es más correcto y son menos líneas. Rara vez coinciden las tres cosas.

La opción que no añadí

La complejidad no siempre entra por la puerta técnica. Muchas veces entra por la puerta de la reunión, disfrazada de amabilidad: ya que estamos, podríamos dejar que se pueda elegir entre estas tres disposiciones. Y como decir que sí es agradable y decir que no parece poco profesional, se añade la opción.

Cada opción que se añade multiplica el sistema por dos. Dos caminos que probar, dos maneras de que se rompa, dos posibilidades de que alguien elija la mala. Cinco opciones aparentemente inocentes son treinta y dos combinaciones, y te garantizo que nadie va a probar treinta y dos combinaciones. También hay una cuestión de honestidad: un panel lleno de conmutadores suele significar que quien lo construyó no fue capaz de decidir y le pasó la decisión al cliente, que sabe todavía menos y que en el noventa por ciento de los casos dejará los valores por defecto.

Ahí está la clave, de hecho. Si casi todo el mundo va a dejar los valores por defecto, el trabajo real consistía en acertar con los valores por defecto. Lo demás era ruido con interfaz. Una opción se justifica cuando hay usuarios reales con necesidades genuinamente opuestas; el resto del tiempo es una decisión que no quisimos tomar.

Simplificar no es ir de rebajas

Conviene aclarar algo, porque este discurso se malinterpreta con facilidad. Simplificar no es hacer menos, ni entregar menos, ni cobrar menos. Es más difícil que lo contrario. Instalar la librería te lleva un minuto; entender el problema lo bastante bien como para darte cuenta de que no necesitas la librería te lleva una tarde, y a veces esa tarde acaba contigo leyendo documentación que llevabas diez años sin abrir.

La solución sencilla llega casi siempre al final, no al principio. Primero construyes la versión complicada, porque es la única que se te ocurre con lo que sabes ese día. Después la usas, la mantienes, te tropiezas con ella un par de veces y un martes cualquiera ves el atajo que estaba ahí desde el principio. Escribir poco es caro por adelantado y barato después. Escribir mucho es exactamente al revés, y por eso gana tantas veces: el coste llega cuando ya has facturado.

Tampoco es una cuestión de austeridad estética ni de fetichismo por lo minimalista. No se trata de hacer webs feas en blanco y negro para demostrar pureza de espíritu. Se trata de que cada cosa que metes tenga que justificar su presencia, igual que cada prenda que cabe en el equipaje de mano. La animación que aporta algo se queda. La que está porque quedaba moderna en 2021, se va.

El sitio que quiero encontrarme dentro de diez años

Este blog es un montón de archivos de texto que se convierten en HTML. No tiene analítica, no tiene banner de cookies, no tiene un panel de administración que actualizar los martes. No lo hice así por ideología, o no solo: lo hice así porque quiero poder abrirlo dentro de diez años y que siga funcionando sin arqueología. Los archivos de texto tienen esa virtud rara de sobrevivir a las modas.

Cuando me toca decidir si algo entra o no entra en un proyecto, la pregunta que mejor me funciona no es si aporta valor —todo aporta algo, esa pregunta siempre da que sí—, sino qué pasa si lo quito. Si la respuesta es nada grave, ya está contestada. Y si la respuesta es no lo sé, peor todavía, porque significa que ese trozo de código ya se ha vuelto opaco y que dentro de tres años lo tendré ahí, intocable, dándome miedo.

La parte incómoda de todo esto es que el trabajo bien hecho, en este oficio, tiende a parecerse a que no has hecho nada. Una web que carga rápido, que funciona con el teclado, que no se rompe al actualizar y que no exige mantenimiento no llama la atención de nadie. Nadie escribe para felicitarte por la dependencia que no instalaste ni por la opción que no añadiste. Me he acostumbrado, y hasta le he cogido el gusto: es un tipo de orgullo silencioso, parecido al de viajar ligero, que solo entiendes del todo cuando ves a los demás esperando en la cinta.