De un bug de 3 días a un ritual de revisión que ahora uso siempre

Hace unos meses conté acá un bug que me tomó tres días encontrar: cuatro líneas de código, un problema de validación asíncrona que nadie vio venir. Lo que no conté en ese momento es lo que cambié en mi forma de trabajar después de eso, y cómo terminó afectando a todo mi equipo.

El ritual que empecé a seguir

Antes de dar por terminada cualquier función que dependa de datos que llegan de forma asíncrona, ahora me obligo a escribir en voz alta, literal, hablando sola, qué pasa si esos datos llegan tarde, llegan en otro orden, o no llegan nunca. Suena simple, pero ese ejercicio de tres preguntas me hubiera ahorrado los tres días completos de aquel bug.

Cómo se lo llevé al equipo

No quise imponerlo como regla obligatoria, porque las reglas impuestas rara vez se sostienen en el tiempo. Lo compartí como una historia real en nuestro canal de equipo, con las cuatro líneas exactas del bug y el tiempo que me costó encontrarlo.

Lo que pasó después

Dos compañeros empezaron a hacer la misma pregunta antes de sus propios pull requests, sin que nadie se los pidiera. No porque yo lo mandaté, sino porque el costo real de no hacerlo quedó bien claro con un ejemplo concreto, no con una norma abstracta de buenas prácticas.

Compartir el error específico, con sus cuatro líneas exactas y las horas reales que costó, convenció más que cualquier checklist genérica que hubiéramos podido escribir.

Lo que aprendí de esto

Las mejores prácticas que de verdad se quedan en un equipo casi nunca llegan como una regla escrita en un documento. Llegan como una historia real que alguien vivió y contó con honestidad, incluyendo la parte incómoda de haber tardado tres días en encontrar algo tan pequeño.

Sigo publicando estos errores acá, aunque a veces dan un poco de vergüenza. Es la forma que encontré de convertir mi peor semana de debugging en algo que le sirve a alguien más antes de que le pase lo mismo.