System 1 vs System 2 al Depurar: Bugs de Madrugada Cuestan 3× Más

Durante cuatro semanas medí cuánto tardaba en depurar bugs a distintas horas del día. Las sesiones nocturnas, entre las 23

y las 3, se llevaban en promedio 3.1× más tiempo que las de la mañana para bugs de complejidad similar. Y el tiempo era la parte fácil. La probabilidad de que el “fix” de madrugada rompiera algo más en producción también subía.

Detrás del cansancio había alguien más: Daniel Kahneman.

Kahneman, para quien no leyó el libro

En Thinking, Fast and Slow (2011), Kahneman describe dos formas de pensar. El Sistema 1 va rápido y automático: funciona sin esfuerzo consciente, tirando de intuición. El Sistema 2 va más despacio: analiza con cuidado y quema mucha energía mental. La regla del cerebro es simple: si el Sistema 1 puede con ello, tira de ahí. Solo cuando el Sistema 1 se declara incompetente aparece el Sistema 2, y aun así con desgana.

Debugging es un trabajo del Sistema 2 disfrazado de trabajo del Sistema 1.

Cuando ya has identificado el bug y estás cambiando dos líneas, es Sistema 1: patrón conocido, los dedos van solos. Pero identificar el bug (leer el stack trace, plantear hipótesis, descartarlas, seguir el flujo entre tres archivos) es Sistema 2 puro. Y el Sistema 2 se agota como un músculo.

Por qué la madrugada te destroza el Sistema 2

Después de las diez de la noche, el Sistema 2 ya lleva 14 o 16 horas trabajando. No rinde igual que a las nueve de la mañana. Y lo que ocurre entonces es peor que “no poder pensar”: el Sistema 1 empieza a hacerse pasar por el Sistema 2 sin que te des cuenta.

Los síntomas concretos que aparecieron en mis 4 semanas de registro:

• Falsa certeza: “Ya sé qué es.” Pues no. A las 2 de la madrugada, seis de cada diez veces mi diagnóstico inicial estaba mal. A las 10 de la mañana, dos de cada diez.
• Parches locales para problemas sistémicos: cambiaba una condición dentro de un if cuando la raíz estaba en que la función se llamaba desde tres sitios distintos con datos inconsistentes. El Sistema 1 vio el síntoma, propuso un parche y cerró el ticket. El Sistema 2 habría notado el patrón.
• Regresiones al día siguiente: el 41% de mis parches nocturnos necesitó un ajuste de seguimiento en las 72 horas posteriores. En los matutinos, ese número bajaba al 9%.

El Sistema 2 exhausto no se apaga: se disfraza de Sistema 1, con la factura mucho más alta. Crees que estás analizando. En realidad estás corrigiendo por patrón, con una confianza que no te has ganado.

Los tres tipos de bug que amplifican el efecto

Bajo fatiga, no todos los bugs pesan lo mismo. Estos tres son los que más se agravan de madrugada:

Bugs de concurrencia. Piden mantener 3-5 hilos mentales en paralelo. Justo lo que el Sistema 2 exhausto ya no aguanta. A la mañana siguiente, el mismo bug se resuelve en 20 minutos. A las 2 de la madrugada, se te van 3 horas y acaba con un sleep(100) que “parece funcionar”.

Bugs de configuración cruzada. Cuando la raíz está en la interacción entre dos archivos de configuración o dos servicios, toca reconstruir el modelo mental entero del sistema. El Sistema 2 fresco lo monta en 10 minutos. El Sistema 2 exhausto lo monta mal y saca la conclusión equivocada.

Bugs intermitentes. Los peores. Perseguir un bug que aparece una de cada 20 peticiones exige paciencia analítica pura. El Sistema 1 propone “es race condition” y cierra el ticket. Dos semanas después, el bug vuelve.

Los bugs simples (un typo, un null sin comprobar, un import mal escrito) se resuelven bien de noche. El Sistema 1 los ve como Sistema 1 y ya está. Es con los bugs que necesitan Sistema 2 de verdad cuando la hora del día decide el resultado.

Los tres cambios que hice en 4 semanas

Después de mirar los datos hice tres cambios. Ninguno heroico.

Regla del reloj. A partir de las diez de la noche no toco ningún bug catalogado como “concurrencia”, “estado global” o “intermitente”. Los aparco con una nota bien clara para el yo de la mañana siguiente: “Requiere Sistema 2, no malgastes Sistema 1 en esto”. Suena rígido, pero me ha ahorrado unos cuantos parches-que-rompen-cosas.

Escritura antes que teclado. Antes de tocar código de noche, escribo en 3-4 frases qué creo que está pasando y qué pruebas tengo. Poner las cosas por escrito obliga al Sistema 2 a despertarse aunque sea un minuto. Si al escribirlo suena flojo, es que el Sistema 1 estaba montando la historia. Ahí sé que toca parar.

Auditoría al día siguiente. Los cambios posteriores a las diez de la noche llevan la etiqueta late-night-fix en el commit. A la mañana siguiente reviso todas las etiquetas de la noche anterior con el Sistema 2 despierto. En 4 semanas, 8 de 19 cambios etiquetados necesitaron un repaso. Solo ese proceso me ahorró tres incidentes en producción.

Un caso concreto que me convenció

Una noche, a la 1

de la madrugada, estaba peleándome con un WebSocket que se caía a los 30 segundos en producción y no en desarrollo. Después de 90 minutos, mi cerebro exhausto sentenció que era un problema de timeout del balanceador de carga y añadí keepalives del lado del cliente. Despliegue, listo, a dormir.

A la mañana siguiente me di cuenta: los keepalives no habían servido de nada. La conexión seguía cayéndose. En 15 minutos de Sistema 2 despierto vi que el problema era una configuración de límite de mensajes por segundo en un proxy intermedio; nada que ver con el timeout. Los keepalives habían sido puro ruido. Mi Sistema 1 exhausto decidió que “keepalive suena a arreglo de WebSocket” y cerró el caso mental.

Moraleja: si a las 2 de la madrugada tu diagnóstico incluye la palabra “seguramente”, no es diagnóstico. Es el Sistema 1 firmando papeles del Sistema 2.

Lo que este dato no dice

No estoy diciendo que nadie deba trabajar de noche. En equipos globales con turnos de guardia, alguien tiene que cubrir la madrugada. Lo que sí propongo es que reconozcas cuándo estás cambiando de Sistema y cuánto te sale ese cambio. Perseguir el bug fácil de noche está bien. Perseguir el bug complejo de noche, con la mañana a 6 horas de distancia, casi nunca compensa.

Quienes trabajamos en remoto para equipos de otros husos horarios sabemos que las ventanas de “hora tranquila” suelen caer a la noche local, y ahí la pregunta se vuelve práctica. La ventana silenciosa parece productiva. La medición dice otra cosa. Sistema 2 cansado + horario disponible = deuda técnica que pagas al día siguiente con intereses.

Kahneman no escribió Thinking, Fast and Slow pensando en programadores. Pero si su tesis principal vale para el juicio humano en general, vale también para el debugging. Ahí el juicio malo se paga caro, y el Sistema 1 se disfraza de Sistema 2 justo cuando menos falta hace.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev