Cuando programar era leer manuales, probar y equivocarse

Hoy tenemos una ventaja enorme: buscas un error, copias un mensaje, preguntas a una IA, miras un foro, ves un vídeo y en pocos minutos tienes una respuesta bastante orientada.

Antes no era así.

Antes aprender informática era mucho más lento. Y aunque suene raro, creo que eso tenía algo bueno.

Cuando empecé, la forma normal de aprender era leer manuales, mirar ejemplos, copiar listados de revistas, probar cambios y equivocarte. Mucho.

No había una respuesta inmediata. Había que pelearse con el problema.

El manual era parte del ordenador

Con el ZX Spectrum, el manual no era un adorno. Era casi una extensión de la máquina.

Ahí aprendías qué era una variable, cómo funcionaba un bucle, para qué servía una condición, cómo usar RND, cómo guardar datos, cómo saltar a una subrutina o cómo repetir una parte del programa.

Leías un ejemplo, lo copiabas, lo ejecutabas y luego empezaba lo divertido: cambiarlo.

¿Qué pasa si aumento este número? ¿Y si cambio esta condición? ¿Y si en vez de imprimir texto dibujo algo? ¿Y si repito esto más veces? ¿Y si uso otra variable?

Ese era el aprendizaje real.

No memorizar comandos, sino entender qué pasaba cuando los tocabas.

Copiar listados también enseñaba

Durante años, muchas revistas publicaban listados de código.

En mi caso, muchas veces aquello venía de revistas como MicroHobby y Micromanía. Con el tiempo algunos recuerdos se mezclan, pero sí tengo muy clara la sensación: aquellas revistas me abrían una puerta enorme al mundo del Spectrum, a los listados en BASIC, a los trucos, a los POKE, a las rutinas y a esa idea de mirar qué había por debajo de lo que aparecía en pantalla.

MicroHobby tenía esa parte más técnica y cercana al Spectrum: listados, explicaciones, rutinas, memoria y ganas de entender cómo funcionaban las cosas por dentro. Micromanía, por su parte, conectaba mucho con el mundo de los juegos, los trucos, las cargas, los mapas y esa cultura de quiosco que también formaba parte de aprender informática en aquella época.

Con esas revistas aprendías copiando, pero también modificando. No se trataba solo de teclear lo que venía publicado. Lo interesante empezaba cuando cambiabas una línea, tocabas un valor, probabas un POKE o intentabas entender por qué aquello hacía lo que hacía.

Visto con el tiempo, aquello ya tenía algo de reversing en estado primitivo: observar, tocar, comparar el resultado y empezar a intuir que debajo de la pantalla había memoria, direcciones, rutinas y lógica.

Los copiabas línea a línea. Si te equivocabas en un carácter, el programa no funcionaba. Y entonces tocaba revisar.

Visto desde hoy parece una tortura. Pero enseñaba mucho.

Te obligaba a leer código despacio. A detectar diferencias. A entender que un símbolo mal puesto podía cambiarlo todo. A tener paciencia.

También enseñaba algo que sigue siendo básico: cuando algo falla, no siempre falla donde tú crees.

Y lo peor es que muchas veces el fallo no estaba donde tú estabas mirando. Estaba antes. En una línea mal copiada, en una variable que no valía lo que pensabas, en un bucle que no terminaba o en una condición que parecía bien escrita, pero no lo estaba.

Y no había nadie que te lo solucionara.

La paciencia también venía de la cinta

Otra parte de aquel aprendizaje era el cassette. Cargar o guardar un programa no era darle a sincronizar y olvidarte. Era esperar, escuchar aquel ruido tan característico, ver las rayas en los bordes de la pantalla y confiar en que la carga terminara bien.

Había algo casi hipnótico en aquello: el sonido de la cinta, las bandas de color, la imagen de carga apareciendo poco a poco, raya a raya. Si todo iba bien, el juego arrancaba. Si algo fallaba, tocaba volver a empezar.

A veces había que ajustar el volumen para que leyera correctamente. Otras veces la cinta se atascaba dentro del cassette y salía arrugada, como un acordeón. Entonces tocaba recuperarla con paciencia, muchas veces usando un bolígrafo BIC para volver a enrollarla a mano.

También recuerdo hacer copias de mis juegos originales para evitar que se estropearan. No era una cuestión de comodidad: era supervivencia doméstica de aquella época. Las cintas se desgastaban, se enganchaban y podían dejarte sin juego.

Incluso había veces en las que tocaba ajustar el cabezal del reproductor con un destornillador muy fino para que leyera mejor. No hacía falta entender todavía toda la electrónica que había detrás, pero sí aprendías algo importante: la informática no era solo software. También dependía del soporte, del ruido, del ajuste, del hardware y de la paciencia.

Ese tiempo muerto también enseñaba. Te obligaba a pensar antes de tocar, a no cambiar veinte cosas a la vez y a valorar cada avance pequeño.

Buscar información también era parte del aprendizaje

La información no estaba siempre delante. Había revistas, manuales, libros prestados, biblioteca pública y bibliotecas de universidad. A veces encontrar una explicación medio clara ya era un pequeño logro.

Hoy buscas una duda y aparecen cientos de resultados. Entonces muchas veces tenías que buscar físicamente el libro, localizar el capítulo, leer despacio y volver a casa con una idea para probar.

No era conocimiento inmediato. Era búsqueda, lectura, paciencia y prueba. Y eso también dejaba poso.

Aprender lento deja poso

No idealizo aquella época. Era más incómoda, más limitada y muchas veces desesperante.

Pero aprender lento tenía una ventaja: te obligaba a construir criterio.

No podías copiar una solución sin entender nada, porque muchas veces no había solución que copiar. Tenías que investigar.

Eso te enseñaba a descomponer problemas:

qué quiero que haga el programa,
qué está haciendo realmente,
dónde cambia el valor,
qué condición no se cumple,
qué parte puedo aislar,
qué puedo probar sin romperlo todo.

Ese método sigue siendo útil hoy.

Da igual que estés mirando un script, un contenedor Docker, una automatización de Home Assistant, una alerta de seguridad o un modelo de IA local. La base es parecida: entender, aislar, probar y corregir.

El error como profesor

Una de las mejores cosas que te daba aquella forma de aprender era perder el miedo al error.

El error no era una excepción. Era parte del proceso.

Escribías algo, fallaba, mirabas, cambiabas, volvía a fallar, corregías otra cosa y al final funcionaba. Y cuando funcionaba, entendías más que si alguien te hubiera dado la respuesta hecha.

En BASIC había muchos errores pequeños que podían romperlo todo: un número de línea mal copiado, un GOTO que saltaba donde no debía, un bucle que no terminaba, una variable mal escrita, un carácter cambiado en un listado o una condición que parecía correcta pero no lo era.

Además, antes programabas muchas cosas que hoy das por hechas. La lógica, la pantalla, los bucles, la entrada de datos, los mensajes, el flujo completo del programa. No había librerías ni frameworks resolviéndote media aplicación. Eso hacía que cada error fuera más visible y, al mismo tiempo, más útil para aprender.

Ese aprendizaje me ha acompañado siempre.

Hoy sigo prefiriendo probar en un entorno controlado antes que creerme una presentación perfecta. Sigo mirando logs. Sigo haciendo pruebas pequeñas antes de tocar algo grande. Sigo desconfiando de las soluciones que parecen mágicas.

Porque muchas veces lo que marca la diferencia no es saber más comandos. Es saber cómo pensar cuando algo no funciona.

De aquellos manuales a la tecnología actual

La tecnología ha cambiado muchísimo, pero no cambió de golpe. La he ido viendo cambiar por capas.

Primero fueron aquellos ordenadores de 8 bits, los manuales, las revistas, las cintas y la sensación de que todo estaba muy cerca del hardware. Luego llegó el PC compatible, MS-DOS, los disquetes, los primeros entornos gráficos y esa idea de que el ordenador empezaba a convertirse en una herramienta de trabajo para muchas más cosas.

Después vinieron las redes, Novell, TCP/IP, Windows NT, los módems, Internet, los foros, la web y una forma completamente distinta de buscar información, comunicarse y aprender. Aquello también cambió el mundo. De repente, muchas cosas que antes dependían de una revista, un manual o una biblioteca empezaron a estar a una búsqueda de distancia.

Más adelante llegaron la virtualización, los servidores, la monitorización, la automatización, el cloud, los smartphones, la ciberseguridad como preocupación constante, la resiliencia, los proveedores críticos y los riesgos TIC. La tecnología dejó de ser solo una herramienta técnica y pasó a ser parte de la continuidad de cualquier organización.

Y luego llegó la IA generativa. Con la IA me pasó algo parecido a lo que años antes había ocurrido con Internet: al verla funcionar por primera vez tuve la sensación clara de que el mundo acababa de cambiar. No era una herramienta más. Era una tecnología llamada a transformar la forma de trabajar, aprender, crear y tomar decisiones.

Pero precisamente por eso creo que el criterio técnico es más importante que nunca. Una IA puede ayudarte muchísimo y también puede darte una respuesta convincente y equivocada. Puedes usar mejores herramientas, pero tienes que seguir entendiendo qué estás haciendo.

Por eso, la forma de aprender que me dejó aquella época sigue siendo válida.

Leer. Probar. Romper. Entender. Documentar.

No quedarse solo en la superficie.

Y sobre todo, no perder la curiosidad.

Porque al final, aunque las herramientas cambien, la actitud sigue siendo la misma.

En el siguiente artículo seguiré avanzando en esa misma línea: cómo los juegos, los trucos, los POKE y las primeras modificaciones me enseñaron a mirar la memoria, la lógica interna y los sistemas de otra manera.