Los hábitos que separan diez minutos de un día entero

Dos ingenieros con la misma experiencia, las mismas herramientas y el mismo problema pueden tardar diez minutos y ocho horas respectivamente, y la diferencia casi nunca está en el conocimiento. Está en un conjunto pequeño de costumbres que se aplican antes de que el problema aparezca, durante la sesión y después de resolverlo. Ninguna es difícil, todas son adquiribles deliberadamente, y esta es la última lección del track porque es la única cuyo efecto se nota en todos los problemas y no en uno.

Las doce costumbres

Antes: las cuatro de preparación

Uno: el entorno preparado. Las DevTools configuradas de una vez y para siempre. La lista de ignorados con tus dependencias, la conservación del registro activada, las columnas útiles añadidas al panel de red, la ralentización de CPU puesta por defecto, la caché desactivada mientras el panel esté abierto. Todo eso está en los ajustes que importan, cuesta veinte minutos una vez, y cambia todas las sesiones futuras.

Dos: el código instrumentado. Clases con nombre en lugar de literales anónimos, funciones con nombre en lugar de flechas anónimas en los sitios que aparecen en pilas, medidas de rendimiento con vocabulario de tu producto, atributos de prueba en los elementos interactivos, señales de estado en el marcado. Cada una de esas cosas cuesta minutos al escribir el código y ahorra horas al depurarlo, y todas benefician además a otras cosas: pruebas, accesibilidad, informes de error.

Tres: la caja de herramientas propia. Los fragmentos que usas a menudo, guardados como snippets, ejecutables desde el menú de comandos. La colección concreta está en diseñar tu caja de herramientas, y el criterio es simple: si has escrito lo mismo en la consola tres veces, guárdalo.

Cuatro: la referencia calibrada. Saber qué aspecto tiene tu aplicación cuando va bien. Un perfil de rendimiento guardado, una sesión de memoria sobre un ciclo sano, el número de peticiones de una carga normal, el tamaño del paquete de la semana pasada. Sin referencia, cada medición hay que interpretarla; con referencia, cada medición es un delta.

Durante: las cinco de sesión

Cinco: escribir el síntoma antes de tocar nada. Sin palabras causales. Es la costumbre que más rendimiento da de las nueve y la que menos gente tiene.

Seis: comprobaciones baratas primero, siempre en el mismo orden. Incógnito, consola, red, incidencias, condiciones. Dos minutos, y una fracción muy grande de los problemas queda acotada a una familia antes de haber leído una línea de código.

Siete: una variable cada vez. Un cambio, una comprobación, una conclusión. Dos cambios simultáneos producen una observación que no significa nada.

Ocho: anotar lo descartado. En un fichero, en un comentario, en el cuaderno de la consola. Da igual el soporte; lo que importa es que a las dos horas no dependas de la memoria.

Nueve: volver al estado limpio periódicamente. Cada vez que la página lleve más de unas cuantas modificaciones encima, recarga en limpio y comprueba que el síntoma sigue siendo el mismo.

Después: las tres de cierre

Diez: explicar el mecanismo antes de dar por cerrado. Escribir una frase que diga por qué ese cambio produce ese síntoma. Si no puedes escribirla, no lo has arreglado: lo has tapado.

Once: convertir el bug en una prueba. El caso mínimo que construiste durante la reducción ya es casi una prueba de regresión; formalizarlo cuesta poco y garantiza que no vuelva.

Doce: preguntar de dónde salió la clase de bug. No este bug concreto, sino su categoría. ¿Es una fuga por un escucha que nadie quitó? Entonces la pregunta es cuántos sitios más tienen el mismo patrón, y si hay una forma estructural de que deje de ser posible. Ese salto de lo particular a lo estructural es lo que hace que un equipo mejore en lugar de arreglar los mismos bugs con nombres distintos durante años.

Cómo se adquieren

Leer una lista de hábitos no produce hábitos. Cuatro mecanismos que sí funcionan, en orden de eficacia.

Reducir la fricción hasta que la costumbre sea el camino más fácil. No es cuestión de disciplina: si el fragmento está guardado como snippet y se ejecuta escribiendo tres letras en el menú de comandos, lo usarás; si hay que buscarlo en un fichero y pegarlo, no. La mayor parte del trabajo de adquirir un hábito consiste en montar el atajo, no en acordarse.

Una sola costumbre a la vez, durante dos semanas. Intentar cambiar cinco cosas de golpe no funciona. Elige una, aplícala conscientemente durante dos semanas hasta que sea automática, y pasa a la siguiente. Doce costumbres son seis meses, y es un plazo realista.

Un disparador explícito. Cada costumbre necesita un momento concreto que la active. “Al empezar a investigar cualquier bug, abrir el fichero de notas y escribir el síntoma” es un disparador; “ser más metódico” no lo es.

Depurar con otra persona de vez en cuando. Es el mecanismo de transmisión más eficaz que existe para esto, porque los hábitos de depuración son observables y no explicables. Media hora mirando trabajar a alguien más rápido enseña más que cualquier texto, incluido este, y el efecto es simétrico: quien explica lo que está haciendo descubre sus propios saltos.

Lo que queda cuando las herramientas cambien

Este track ha recorrido paneles que van a cambiar. Las pestañas se moverán, los ajustes cambiarán de sitio, aparecerán funciones nuevas y desaparecerán otras. Por eso todo lo que has leído está descrito por su función y no por su ubicación, y por eso los atajos van siempre en pareja y las rutas se buscan por nombre en el menú de comandos.

Lo que no va a cambiar es más pequeño de lo que parece y cabe en unas pocas frases.

Observar antes de intervenir, porque cada intervención destruye evidencia.

Acotar antes de medir, porque una medición sobre un espacio grande es ilegible.

Medir antes de arreglar, porque la intuición sobre rendimiento se equivoca sistemáticamente.

Bisecar siempre que haya una prueba fiable, porque converge sin necesidad de entender.

Explicar antes de cerrar, porque un síntoma que desaparece no es un problema resuelto.

Y preguntar por la categoría, porque arreglar un bug es trabajo y eliminar una clase de bug es progreso.

Seis frases. Todo lo demás de este track son instrumentos para aplicarlas.