Este artículo puede incluir enlaces de afiliado. Si compras a través de ellos, me llevo una pequeña comisión sin coste extra para ti. Más información.
El bug llevaba tres días mirándome a la cara. Tres días de logs, de añadir prints por todas partes, de reescribir fragmentos que funcionaban perfectamente, de convencerme de que el problema era algo profundo e invisible. Spoiler: era una comparación con == donde debería haber usado .equals(). Una de las primeras cosas que aprendes en Java. Una de esas cosas que haces mal cuando tienes dieciséis años y nunca más en tu vida. Pues sí. A mí me pasó con cuarenta.
Cómo empieza la ceguera
El contexto era un servicio que procesaba notificaciones. Nada del otro mundo. En algún punto de la lógica, un objeto de tipo String llegaba desde fuera —de una caché, para ser exactos— y yo lo comparaba contra una constante. La comparación devolvía false cuando debería haber devuelto true. Hasta ahí, claro. El problema es que yo sabía que ese código era correcto. Lo había escrito yo. Lo había revisado yo. Llevaba meses funcionando en otro contexto parecido.
Y ahí está la trampa. Cuando tú mismo has escrito algo, no lo lees. Lo reconoces. Tu cerebro rellena los huecos con lo que espera ver, no con lo que hay. Es como leer un texto con erratas: si lo escribiste tú, puedes pasarte horas sin verlas porque tu memoria sabe lo que querías poner.
Así que durante tres días busqué el problema en todos sitios menos donde estaba. Revisé la caché. Revisé la serialización. Revisé si había algún problema con los threads. Llegué a pensar que quizás la JVM estaba haciendo algo raro con el interning de Strings en esa versión concreta. Sí, llegué a ese punto. Cuando empiezas a sospechar de la JVM, algo ha salido muy mal en tu proceso mental.
El papel del cansancio
No dormía bien esa semana. Tenía en acogida a una gata recien llegada y los primeros días siempre son caóticos. Maullidos de celo a las tres de la mañana, mis gatos mirándome con una expresión que claramente significaba esto es culpa tuya. Me levantaba ya con la cabeza a medio gas.
Y el cansancio hace algo muy concreto cuando programas: te vuelve conservador. Evitas cuestionar lo que crees que ya sabes porque cuestionar cuesta energía. Tu cerebro, en modo ahorro, tiende a confirmar sus hipótesis en vez de descartarlas. Buscas evidencia de que el problema está en la caché porque eso encaja con tu teoría, y cuando no la encuentras, buscas otra teoría igual de complicada en vez de dar un paso atrás.
Lo peor es que esto no lo notas mientras ocurre. Crees que estás siendo metódico. Crees que estás descartando opciones de forma racional. Pero en realidad estás dando vueltas en círculo con mucha apariencia de movimiento.
Lo que me hizo verlo al final
No fue ningún insight brillante. Fue un compañero que se asomó a mi pantalla un momento, leyó el código durante unos cinco segundos y dijo: ¿ese == es correcto ahí?
Silencio.
El tipo de silencio en el que tu cerebro procesa algo y preferiría no hacerlo.
Lo arreglé en treinta segundos. Luego estuve diez minutos sin decir nada, mirando la pantalla, haciendo las cuentas del tiempo que había perdido. Mi compañero tuvo la delicadeza de no reírse demasiado.
Lo que me resultó útil entender después es por qué él lo vio y yo no. No porque sea mejor programador. Sino porque él llegó sin contexto, sin inversión emocional en ese código, sin la carga de haberlo escrito y haberlo dado por bueno. Lo leyó como texto. Yo lo leía como mi código, que es una categoría completamente distinta.
Lo que cambié después
Revisar el código como si no fuera mío
Suena fácil y no lo es. Lo que sí funciona, al menos para mí, es dejar pasar tiempo antes de revisar algo que acabo de escribir. Si puedo, lo dejo para el día siguiente. Si no puedo, cambio el formato: lo imprimo, lo leo en voz alta, lo pego en un documento de texto sin resaltado de sintaxis. Cualquier cosa que rompa el reconocimiento automático y me obligue a leer de verdad.
También empecé a ser más honesto cuando llevo mucho rato con algo sin avanzar. Antes me daba vergüenza pedir ayuda rápido, como si fuera una señal de que no sabía lo que hacía. Ahora lo veo al revés: llevar tres días solo con un bug que otro ve en cinco segundos es bastante más embarazoso.
Tomar el cansancio en serio
No como una excusa, sino como una variable real. Si llevo una semana durmiendo mal, ciertas tareas que requieren leer código propio con ojo crítico las dejo para momentos mejores si puedo permitírmelo. Y si no puedo, al menos soy consciente de que voy con el handicap puesto.
Escribir me ha ayudado bastante con esto, curiosamente. Cuando corrijo un manuscrito, sé perfectamente que no puedo revisar algo que acabo de escribir: necesito distancia. He tardado años en aplicar la misma lógica al código, que se supone que es mi trabajo principal.
Lo que me quedó de todo esto
La confianza en lo que has escrito es útil hasta que deja de serlo. Te ahorra tiempo la mayor parte del tiempo. Pero cuando hay un bug, esa misma confianza se convierte en el primer obstáculo. Y cuanto más tiempo llevas programando, más automático es ese reconocimiento, y más fácil es que te ciegue.
No creo que haya una solución perfecta. El cerebro va a seguir haciendo lo que hace. Pero desde aquel día intento recordar, cuando llevo demasiado tiempo con algo, que quizás el problema no es invisible. Quizás simplemente estoy mirando sin ver.
Los gatos, por cierto, acabaron entendiéndose a la semana y media. Ahora duermen en el mismo sofá. El código tardó menos.
Foto: a man sitting in front of a computer monitor por l ch en Unsplash.
¿Quieres más?
Recibe los nuevos artículos sobre gatos, escritura y código. Sin frecuencia fija, sin paja de IA, sin spam.
Suscribirme