La Variable que No Vas a Imprimir Es la que Esta Mal

Llevas dos horas con esto. La logica es solida. Ya revisaste todo. La funcion recibe los argumentos correctos, el ciclo termina bien, y el resultado es, de alguna manera imposible, todavia incorrecto.

Excepto que no revisaste todo. Revisaste todo lo que sospechas.

La variable que decidiste que estaba bien

Hay un momento especifico en cada sesion larga de debugging donde tomas una decision ejecutiva silenciosa. Miras una variable (quiza es userConfig, quiza es offset, quiza es parsedDate) y piensas: esa esta bien. Sigues adelante. Instrumentas todo alrededor. Agregas print statements arriba, abajo, a los lados de la llamada a la funcion. Nunca imprimes la variable en si.

Ya sabes lo que contiene.

Excepto que no. Sabes lo que deberia contener. Esas no son la misma cosa, y la distancia entre ellas es exactamente donde vive tu bug.

Esto no es un fallo de inteligencia. Es un fallo de descripcion.

Por que la certeza es el enemigo

La memoria humana no guarda snapshots de estado. Guarda narrativas. Cuando escribiste la funcion que llena userConfig hace tres semanas y funciono, tu cerebro lo archivo bajo “resuelto”. La narrativa cerro. Ahora, cuando estas debugueando algo que viene despues, tu cerebro recupera la narrativa, userConfig funciona, y omite la re-verificacion por completo.

La computadora no le importa tu narrativa. Le importa lo que esta realmente en la variable en tiempo de ejecucion.

La confianza en que una variable es correcta es inversamente proporcional a que tan recientemente la verificaste. Cuanto mas seguro te sientes, mas tiempo ha pasado desde que realmente la miraste.

La espiral de suposiciones

Cada suposicion que haces estrecha tu espacio de busqueda. Ya eliminaste userConfig como sospechosa, entonces te concentras en la siguiente capa. Esa capa te parece mal, no porque lo este, sino porque la estas mirando esperando que este mal. Empiezas a contorsionar tu modelo mental para que encaje. Escribes hipotesis cada vez mas elaboradas. Ninguna da resultado.

Dos horas despues, tienes seis hipotesis incorrectas y una variable sin examinar.

El pato no sabe lo que deberia estar ahi

El metodo de depuracion con pato de goma funciona por una razon mecanica especifica que generalmente se subestima: cuando le hablas al pato, tienes que describir lo que la variable realmente contiene en un punto especifico de la ejecucion, no lo que pretendias que contuviera.

No puedes enganar al pato con intenciones.

Agarra el objeto inanimado mas cercano (una taza de cafe, una grapadora, una lata de lo que sea que estas tomando para aguantar) y explicale userConfig. No “contiene la configuracion del usuario”. Eso es lo que se supone que debe contener. Dile al pato lo que contiene exactamente ahora mismo, en la linea 74, en esta ruta de ejecucion especifica, con este input especifico.

Si dudas, esa es la variable. Imprimela.

Describe el objeto como si fuera fisico

Un encuadre que corta a traves de la niebla: imagina la variable como un objeto fisico que se mueve por una tuberia. Entra a una funcion. Se modifica. Sale. En algun punto de esa tuberia, el objeto que recibes al final es diferente del que esperabas enviar.

Tu trabajo no es encontrar el codigo malo. Tu trabajo es encontrar donde el objeto cambia de forma inesperadamente. No puedes hacerlo mirando la tuberia. Tienes que abrirla y ver que hay adentro, en cada union, incluyendo las que tu mismo instalaste.

La union en la que mas confias es la que debes revisar primero.

La regla de los tres segundos del print statement

Cuando llevas mas de veinte minutos debugueando sin resolucion, aplica esta regla: identifica la variable de la que estas mas seguro. Imprimela. Hazlo antes que cualquier otra cosa.

Tres segundos de console.log(userConfig) o print(offset) o pp parsed_date. Esa es la inversion.

El resultado esperado: ves lo que esperabas, eliminas la variable, perdiste tres segundos. Bien.

El resultado real, la mayoria de las veces: ves algo que no esperabas. Al objeto le falta una clave. La fecha se parseo en UTC en lugar de local. El offset es un string, no un numero, y tu comparacion lo coerciono silenciosamente a basura tres capas mas arriba.

Estuviste trabado dos horas por una coercion de tipos. El print statement tomo tres segundos.

Lo que cuesta la certeza silenciosa

La razon por la que los ingenieros se resisten a imprimir la variable “obvia” no es flojera. Es un mecanismo de proteccion psicologica. Imprimela y esta mal, y tienes que admitir que pasaste dos horas ignorando la respuesta. Eso es incomodo.

Pero ya paso de todas formas. Solo distribuiste ese malestar a lo largo de dos horas en vez de concentrarlo en un momento de tres segundos.

La version de tres segundos es mejor. Imprime la variable.

Articula antes de investigar

Antes de cualquier print statement, hay un paso que no cuesta nada y que muchas veces hace innecesario el print statement. Escribe, no en tu cabeza sino en un archivo de borrador, una oracion completa describiendo lo que la variable contiene en la linea especifica que estas examinando.

No “deberia tener el token del usuario”. Se especifico: “En la linea 89, despues de la llamada a parseResponse, authToken contiene un string en el formato Bearer <jwt>, establecido durante la fase de inicializacion, y la ultima vez que verifique que estaba correctamente poblado fue aproximadamente nunca.”

Esa ultima clausula es la clave. “Aproximadamente nunca” aparece en texto plano. Puedes verlo. Puedes actuar.

La mayoria del debugging no es un problema de logica. Es un problema de descripcion de estado. La logica casi siempre funciona exactamente como esta escrita. Solo opera sobre un estado diferente al que crees.

La variable que estas defendiendo

Cada sesion como esta tiene una variable que estas defendiendo silenciosamente. Ya sabes cual es. Es la variable que escribiste tu, en codigo del que estas orgulloso, que ha funcionado antes. Imprimirla se siente como una acusacion que preferirias no hacer.

Hazla de todas formas.

El codigo no sabe que lo escribiste. No sabe que estas orgulloso de el. Solo corre sobre lo que esta realmente en esa variable, no sobre lo que recuerdas haber puesto ahi.

El pato no te esta juzgando. Esta esperando a que describas el objeto correctamente para que la respuesta se vuelva obvia.

Profundiza: David Agans literalmente escribio el libro sobre esto — Debugging: The 9 Indispensable Rules cubre el enfoque sistematico para encontrar bugs que tu instinto sigue ignorando. Y si quieres un recordatorio fisico para revisar tus suposiciones, nada supera tener un pato de goma real en tu escritorio.

Como Asociado de Amazon ganamos por compras que califican.