La Prueba del Patito de Goma para el Código que Realmente Conoces

La depuración con el patito de goma se enseña como un truco de depuración: explica tu código línea por línea a un objeto inanimado, y el acto de narrarlo en voz alta saca a la luz el error que no podías ver solo leyendo. Esa parte es cierta. Pero el mismo ejercicio también es una prueba genuinamente confiable de otra cosa — si realmente entiendes un fragmento de código, o solo lo reconoces.

Esas dos cosas se sienten idénticas desde adentro. Leer una función y pensar "sí, tiene sentido" es una barra mucho más baja que poder producir una explicación de ella, en voz alta, en orden, sin revisar nada. La brecha entre ambas solo aparece cuando de verdad intentas lo segundo.

Reconocer es barato; explicar es caro

Reconocer es rápido, automático, y no requiere sostener mucho en la cabeza a la vez — solo estás emparejando una forma que ya viste antes. Explicar te obliga a sostener toda la cadena causal: por qué existe esta línea, qué se rompería si no estuviera, por qué el código está estructurado así y no de alguna otra forma razonable. Esa es una operación cognitiva fundamentalmente distinta y más costosa, que es exactamente por qué es una mejor prueba.

Por qué esto importa más ahora, no menos

Esta brecha solía aparecer naturalmente, porque escribir código desde cero te obligaba a pasar por el paso de "explicártelo a ti mismo primero", quisieras o no. Las herramientas de autocompletado ahora son lo bastante buenas como para que mucho código se acepte solo por reconocimiento — se ve bien, funciona, y el paso de explicarlo simplemente nunca ocurre. Eso está bien hasta que una revisión de código, una entrevista o un incidente te pidan producir la explicación en el momento.

Cómo aplicar la prueba de verdad

• Elige código real, no un ejemplo de juguete. Algo que escribiste la semana pasada, o una función de un proyecto del que estás orgulloso. Ponerte a prueba con código que nunca internalizaste de verdad no te dice nada nuevo.
• Explícalo en voz alta, no en tu cabeza. Leer una explicación en silencio te deja saltarte las partes difíciles sin darte cuenta. Decirla en voz alta, o escribirla como si fuera para otra persona, obliga a que cada vacío salga a la luz.
• Nota exactamente dónde te frenas o dudas. "Creo que esta parte maneja el caso donde..." es el sonido del reconocimiento haciéndose pasar por comprensión. Esa es la parte que vale la pena volver a trabajar de verdad.
• Luego intenta modificarlo, en vivo, sin buscar nada. Explicar es una barra; cambiar el comportamiento correctamente al primer intento, sin ayuda, es una más alta — y suele ser la que realmente se evalúa en una entrevista o una sesión de depuración en vivo.

Construir el hábito a propósito

No hace falta esperar a una entrevista para descubrir dónde están los vacíos — puedes ir a buscarlos deliberadamente, en código que ya crees conocer, de forma regular. Es incómodo exactamente de la forma que resulta útil: es la manera más rápida de descubrir que "sé esto" y "puedo producir esto" no son la misma afirmación.

La práctica diaria corta en SoloScript funciona con el mismo principio desde el otro lado — escribir una solución de memoria, sin nada en qué apoyarte, es la prueba del patito de goma incorporada al ejercicio mismo, antes de siquiera llegar a una entrevista donde lo que está en juego es mayor.