Leer y entender código que no escribiste

La tentación es obvia: si corre, sirve; si sirve, sigo. Y mientras el código funcione, tienes razón. El problema aparece el día que falla, porque el código siempre termina fallando: cambian los datos, cambia el requisito, alguien agrega una línea.

Ahí empieza lo que llamamos programar a ciegas. No sabes qué línea tocar, entonces le vuelves a pedir a la IA que lo arregle. La IA cambia algo, el error se mueve a otra parte, le pides otra vez, y en cada vuelta el programa se vuelve más largo y tú entiendes menos. Es un ciclo que se siente productivo y no lo es: al final tienes cien líneas que nadie —ni tú ni la IA, que no recuerda tus decisiones— sabe explicar.

Hay una razón práctica y muy colombiana para no caer ahí. En una entrevista para práctica o primer empleo, hoy casi nadie te va a pedir que escribas un algoritmo complicado desde cero: saben que tienes un asistente. Lo que sí te van a poner es un pedazo de código del equipo para que digas qué hace, qué le falta y qué pasaría si le cambias tal cosa. Esa es la prueba real, y es exactamente la habilidad que vamos a entrenar.

La buena noticia: leer código se entrena, y con un asistente al lado se entrena mucho más rápido, porque tienes un profesor disponible a cualquier hora que te explica el mismo punto quince veces sin cansarse. La diferencia entre quedar adelante o atrás no está en tener la herramienta —todos la tienen— sino en cómo la usas: para que te dé respuestas o para que te enseñe.

Si le escribes a un asistente "explícame este código", te va a devolver un resumen bonito: "este programa calcula el promedio de una lista de notas y determina si el estudiante aprobó". Suena bien, no aprendiste nada. Ya sabías eso por el nombre de las variables.

Una explicación que sí enseña tiene tres ingredientes, y hay que pedirlos explícitamente:

• Qué hace cada línea, una por una, incluidas las aburridas.
• Qué valor queda guardado en cada variable después de esa línea, con números concretos, no en abstracto.
• Por qué se hizo así y no de otra forma; qué alternativa había.

El tercero es el que la gente nunca pide y es el más valioso, porque el código no solo hace algo: hace algo en vez de otra cosa. Entender esa decisión es entender de verdad.

Dos ajustes más que cambian mucho el resultado. Primero, dile tu nivel de forma directa: "nunca he programado, no asumas que sé qué es un bucle". El asistente ajusta el vocabulario y deja de usar palabras que te tocaría buscar aparte. Segundo, pídele que simule la ejecución cuando haya un ciclo, o sea que te muestre vuelta por vuelta cómo cambian los valores. Ver que suma pasa de 0 a 3.5, luego a 7.7, luego a 10.5, hace clic en la cabeza de una forma que ningún párrafo logra.

Y una advertencia: si algo no te queda claro, no sigas. Repregunta sobre esa línea exacta. No es que seas lento; es que ahí hay un concepto nuevo que el asistente se saltó.

Leer una explicación se siente como aprender, pero es engañoso: reconocer algo escrito es mucho más fácil que producirlo tú. La prueba honesta es intentar explicar el código sin mirarlo. Ahí se cae el castillo.

Por eso el movimiento más útil de esta lección es invertir los papeles: en vez de que el asistente te explique, que te examine. Le pides que actúe como profesor, que te haga una pregunta a la vez, que espere tu respuesta antes de continuar y que te diga si estás bien o mal explicando por qué. Una sola pregunta a la vez es importante; si le pides cinco de una, te las responde solo y volviste al modo lectura.

Las preguntas que más enseñan son las de tipo "¿qué pasaría si...?": qué pasa si la lista está vacía, qué pasa si cambio ese >= por >, qué pasa si muevo esa línea dos renglones arriba. Te obligan a correr el programa en tu cabeza, que es justo el músculo que queremos.

Ojo con un defecto real de estos asistentes: tienden a ser complacientes. Si respondes cualquier cosa, muchas veces te dicen "¡exacto, muy bien!" aunque tu respuesta esté a medias. Contrarréstalo pidiéndolo de entrada: "sé estricto, si mi respuesta está incompleta dímelo y señala qué falta". Y cuando te corrija, no aceptes de una: verifica ejecutando el código.

Cierra siempre con el mismo ejercicio: escribe en tres frases, sin mirar la pantalla, qué hace el programa. Si no te salen las tres frases, todavía no lo entendiste, y eso es información valiosa, no un fracaso.

Esta es la técnica central de la lección y es un ciclo de tres pasos que se hace en menos de un minuto:

1. Predecir: escribe (sí, escribe, no lo pienses nomás) qué crees que va a pasar si cambias algo. 2. Cambiar: haz ese cambio, uno solo. 3. Verificar: ejecuta y compara con tu predicción.

Cuando aciertas, confirmaste que entendiste. Cuando fallas —y al principio vas a fallar harto— acabas de encontrar el punto exacto donde tu idea del programa no coincide con la realidad. Ese error vale más que diez explicaciones, porque ya sabes qué preguntar: "pensé que iba a pasar X y pasó Y, ¿por qué?".

Dos reglas para que funcione. Una sola cosa a la vez: si cambias tres y se rompe, no sabes cuál fue. Rompe a propósito: quítale un paréntesis, cámbiale el nombre a una variable en un solo lugar, dividelo entre cero. Ver el error que produce cada daño te enseña a reconocerlo después, cuando aparezca sin que lo hayas buscado.

Sobre el programa de notas de la práctica, estos son cambios chiquitos con mucho jugo:

• Cambiar >= 3.0 por > 3.0 y probar con un promedio de exactamente 3.0.
• Agregar una nota a la lista y ver que el promedio se ajusta solo (ahí entiendes para qué sirve len(notas)).
• Reemplazar len(notas) por el número 5 y volver a agregar una nota: el resultado queda mal, y esa es la lección.
• Cambiar round(promedio, 2) por round(promedio, 0).

Un detalle práctico: antes de romper nada, copia el código original a un lado. Poder volver al estado que funcionaba te quita el miedo a experimentar, y sin experimentar no se aprende esto.

Un programa no se lee como un texto, de corrido. Se lee siguiendo el recorrido de los datos. Tres hábitos concretos:

Primero, ubica entrada, proceso y salida. ¿De dónde salen los datos (una lista escrita a mano, un archivo, algo que el usuario escribe)? ¿Qué se les hace? ¿Qué se muestra al final? Casi cualquier programa que veas cabe en ese molde, y tenerlo claro te dice en qué tercio buscar cuando algo falla.

Segundo, sigue una variable a la vez. Escoge una, por ejemplo suma, y anota en una hoja qué valor tiene en cada vuelta del ciclo. A eso se le dice hacer una tabla de seguimiento y es lo que hacen los programadores con experiencia, mentalmente y a toda hora. Con notas = [3.5, 4.2, 2.8], suma va 0 → 3.5 → 7.7 → 10.5. Cuando ves esos números, el ciclo deja de ser magia.

Tercero, lee de adentro hacia afuera. En print("Promedio:", round(suma / len(notas), 2)) hay cuatro cosas anidadas. Empieza por lo más interno: primero se cuentan cuántas notas hay, luego se divide, luego se redondea a dos decimales, y de último se muestra. Los paréntesis te marcan el orden.

Y los errores: en Python el mensaje se llama traceback y se lee de abajo hacia arriba. La última línea te dice el tipo de error (ZeroDivisionError, NameError, IndentationError) y las de arriba en qué línea pasó. No se lo pegues a la IA de una: primero léelo tú, adivina qué significa, y después pídele que te confirme. Casi siempre el mensaje dice literalmente lo que pasó.

Todo lo anterior asume que la explicación es correcta, y no siempre lo es. Hay que ser honestos sobre esto porque es el punto donde más gente sale confundida.

Estos asistentes generan texto que suena plausible, y una explicación equivocada suena igual de segura que una correcta. No hay señal de alarma en el tono. Tres fallas típicas:

• Te explican la intención, no el comportamiento. Si el código tiene un error, la IA muchas veces te cuenta lo que el código parecía querer hacer, no lo que realmente hace al ejecutarse.
• Inventan funciones o parámetros que no existen en la librería que estás usando, con nombres muy convincentes.
• Se pierden en código largo: en un archivo grande pueden atribuirle a una línea un efecto que en realidad ocurre en otra parte.

El antídoto es siempre el mismo y ya lo tienes: ejecutar. El computador no opina. Si la IA dice "esta línea guarda el promedio", ponle un print(promedio) y mira. Un print bien puesto vale más que tres párrafos de explicación, y es la herramienta de depuración que más usan los programadores profesionales, aunque suene demasiado simple.

Dos cuidados adicionales antes de pegar código en un chat. Uno, no pegues claves ni contraseñas ni tokens de acceso: si están en el código, reemplázalos por XXXX antes de copiar. Dos, no pegues datos personales de otras personas —cédulas, correos, teléfonos, notas de compañeros con nombre propio—; la ley colombiana de protección de datos personales aplica también a lo que subes a un servicio de internet, y además simplemente no es necesario: cámbialos por datos inventados y la explicación sirve igual.