Depurar Sin un Depurador

Depurar hoy depende mucho de las herramientas: breakpoints, ejecución paso a paso, una consola que puedes tocar en vivo, y ahora a veces hasta una IA que te lee el stack trace. Todo eso es genuinamente útil en el día a día. Pero hay una habilidad separada y más antigua debajo de todo eso — leer código y razonar qué hace sin ejecutarlo — y esa es exactamente la habilidad que se pone a prueba en los lugares donde ninguna de esas herramientas está disponible: una ronda de pizarrón, un documento compartido durante una entrevista en vivo, una revisión de PR donde no puedes simplemente poner un breakpoint en la rama de otra persona.

Esto no es un argumento en contra de usar un depurador para trabajo real. Es que la habilidad específica de seguir la ejecución en tu cabeza se atrofia en silencio si nunca se ejercita por sí sola, y suele reaparecer justo en el momento en que menos preparado estás.

Qué es lo que realmente hace un depurador por ti

El valor real de un depurador es que reemplaza la predicción con la observación: en vez de razonar qué debería valer una variable en cierta línea, simplemente ves qué vale en realidad. Eso ahorra muchísimo tiempo, y también significa que puedes entregar código correcto durante años sin nunca practicar el paso de predecir — porque nunca tuviste que hacerlo.

La habilidad de fondo: seguir la ejecución mentalmente

A veces se le llama "ejecutar en seco": rastrear qué guarda cada variable línea por línea, predecir qué va a hacer realmente un bucle antes de ejecutarlo, notar un error de desfase por uno leyendo la condición límite en vez de verla fallar. Es más lento que un depurador. También es la única opción en muchas situaciones que importan.

Dónde se nota la brecha

• Un error que tomaría cinco segundos con un breakpoint te toma varios minutos de mirar fijo. No porque el error sea más difícil, sino porque el músculo para encontrarlo sin ejecutar el código no se ha ejercitado.
• Entiendes cada línea del PR de un compañero pero no puedes predecir el resultado sin ejecutarlo. Esa es una brecha real entre comprensión y predicción, y los revisores la notan.
• Un entrevistador te pregunta qué imprime un fragmento de código, y la respuesta honesta es "déjame ejecutarlo". En una sala sin forma de ejecutarlo, esa respuesta no tiene a dónde ir.
• Un problema para hacer en casa sin salida de consola disponible te deja atascado antes de lo esperado. La ausencia de una herramienta conocida expone exactamente cuánto dependías de ella.

Cómo practicar esto de verdad

La práctica en sí es simple, aunque un poco incómoda al principio: toma una función pequeña, tapa la salida, y predice el resultado exacto línea por línea antes de comprobarlo. Hazlo a propósito y con la frecuencia suficiente para que el paso de predecir deje de sentirse como trabajo extra y empiece a sentirse como el primer movimiento normal.

Esto también se parece a cómo funciona la calificación en SoloScript: en vez de un simple correcto o incorrecto, la retroalimentación señala exactamente dónde falló tu razonamiento, que es su propia versión de seguir lo que realmente pasó en vez de solo saber que algo no funcionó.