Ordenador Sinclair ZX Spectrum utilizado como imagen para un articulo autobiografico sobre los inicios en BASIC, programacion y aprendizaje tecnico.

De BASIC al reversing: cómo aprendí a entender la tecnología por dentro

por

Hay cosas que empiezan como un juego y, con los años, te das cuenta de que te marcaron mucho más de lo que pensabas.

Mi relación con la tecnología empezó así. Con curiosidad. Con ganas de tocar. Con la necesidad de entender qué estaba pasando por debajo.

En 1983 tuve delante un ZX Spectrum de 16 Kb. Aquel ordenador, visto hoy, parece casi imposible: poca memoria, gráficos sencillos, sonido limitado y una forma de trabajar que obligaba a tener paciencia. Pero para mí fue una puerta enorme.

No había Internet. No había YouTube. No había Stack Overflow. No había ChatGPT. Había un manual, listados de código, revistas, pruebas, errores y muchas horas delante de la pantalla.

Y, sobre todo, había una sensación muy potente: si querías que algo funcionara, tenías que entenderlo.

Los primeros programas en BASIC

Empecé con BASIC, como muchos de mi generación.

Al principio todo era muy simple: imprimir texto en pantalla, pedir datos por teclado, hacer bucles, contar puntos, repetir partidas y controlar condiciones. Pero poco a poco aquello iba teniendo sentido.

Recuerdo hacer pequeños juegos propios, versiones sencillas de ahorcado, mastermind y pruebas parecidas. No eran grandes juegos, claro. Pero tenían algo importante: eran míos.

Tenían una lógica, unas variables, unas reglas, unos turnos y una forma de fallar.

Un ahorcado te obligaba a pensar en letras acertadas, intentos fallidos, palabras ocultas y fin de partida. Un mastermind te hacía pensar en combinaciones, posiciones, aciertos, errores y comparación de valores.

Hoy parecen cosas sencillas, pero ahí estaban ya muchas de las bases: variables, condiciones, bucles, memoria, entrada por teclado, estado de partida y depuración casera.

Y cuando algo fallaba, no había mucho misterio: tocaba revisar, cambiar, volver a ejecutar y probar otra vez.

Ese fue el primer aprendizaje importante: programar no era escribir algo y esperar magia. Era pensar, probar, romper, corregir y volver a probar.

Cuando descubrí que la memoria también se podía tocar

Una de las cosas que más me llamó la atención de aquella época fue descubrir que un programa no era solo lo que veías en pantalla.

Detrás había memoria. Había posiciones. Había valores. Había números que cambiaban cosas.

Ahí entraban comandos como POKE, que permitían escribir valores directamente en memoria. Para un niño o un chaval curioso, aquello era casi abrir una puerta secreta.

De repente entendías que un juego podía guardar el número de vidas en una posición, que una puntuación era un valor, que un comportamiento podía depender de un byte. Y entonces empezabas a probar.

Buscar vidas infinitas en juegos, modificar valores, cambiar algo a FF en hexadecimal —255 en decimal— y ver qué pasaba. No era solo hacer trampas. Era descubrir que detrás del juego había datos, memoria y lógica.

Si cambiabas un valor, pasaba una cosa. Si tocabas otro, se rompía. Si lo devolvías, volvía a funcionar. Era una forma muy directa de aprender causa y efecto dentro de un sistema.

Ese tipo de aprendizaje se te queda.

Porque deja una idea muy clara: lo que ves en pantalla es solo una consecuencia. Lo importante muchas veces está debajo.

Del Spectrum al PC

Con el PC llegó otra etapa.

Ya no era solo BASIC ni juegos sencillos. Empecé a tocar dBASE, Clipper, aplicaciones de gestión, bases de datos, pantallas, listados, menús, compilación y ejecutables.

Aquello era distinto.

Estabas empezando a ver que la informática no servía solo para experimentar o jugar. También servía para organizar trabajo real.

dBASE y Clipper tenían algo muy potente para la época. Permitían crear aplicaciones de gestión con datos, formularios, búsquedas, informes, menús y lógica de negocio.

No era tan vistoso como un juego, pero enseñaba algo igual de importante: la tecnología también sostiene procesos.

Una aplicación podía guardar clientes, pólizas, facturas, movimientos, listados o cualquier otro dato importante. Y si algo fallaba, no era solo un error en una pantalla. Podía afectar al trabajo de alguien.

Ahí empecé a entender que programar no era solo resolver un problema técnico. Era entender qué necesitaba una persona, cómo trabajaba, qué datos usaba y cómo convertir todo eso en una herramienta.

También empecé a ver otra cosa: cuando compilas y entregas algo que otros van a usar, ya no vale con que funcione una vez en tu máquina. Tiene que arrancar, mantenerse, recuperarse y ser entendible.

Sin llamarlo así, aquello ya empezaba a enseñarte despliegue, dependencias, soporte y continuidad.

Mirar dentro de los programas

Después llegó otra fase: mirar ejecutables por dentro.

Editores hexadecimales, depuradores, desensambladores, ejecutables DOS y Windows, estructuras PE, cadenas de texto, llamadas, saltos, registros, direcciones, CALL, JMP y flujo de ejecución.

No era una forma cómoda de aprender. Era lenta, a veces frustrante y muchas veces bastante oscura. Pero también era fascinante.

La interfaz te decía una cosa, pero el ejecutable contaba otra.

Un botón hacía algo porque detrás había instrucciones. Una validación saltaba a una dirección. Una comparación decidía si el programa seguía por un camino o por otro. Un mensaje de error aparecía porque antes se había tomado una rama concreta.

Ahí aprendías a seguir el rastro.

Mirabas una cadena de texto. Buscabas dónde se usaba. Seguías una llamada. Veías un salto condicional. Mirabas qué valor había en un registro. Intentabas entender por qué el programa había llegado hasta ahí.

No se trataba de tocar por tocar. Se trataba de entender.

Un programa no era una caja negra. Se podía observar. Se podía seguir. Se podía razonar.

Lo que me enseñó el reversing

Con el tiempo entendí que el reversing me estaba enseñando algo más amplio que una técnica concreta.

Me estaba enseñando a no fiarme solo de la superficie.

Una interfaz puede ocultar mucho. Un mensaje puede no contar toda la historia. Un error puede ser consecuencia de algo que ocurrió mucho antes. Una decisión del programa puede depender de un valor que no estás viendo.

Eso sigue siendo válido hoy.

Cuando revisas un log, cuando analizas una incidencia, cuando miras una configuración, cuando pruebas una automatización, cuando revisas un proveedor o cuando intentas entender por qué un sistema no responde como debería, la lógica es muy parecida.

No basta con mirar el síntoma.

Hay que seguir el camino.

Lo que se quedó de todo aquello

Con los años he trabajado en muchas cosas: programación, sistemas, servidores, seguridad, proveedores, continuidad, riesgos TIC, infraestructura, cloud, automatización, IA local y gestión tecnológica.

Las herramientas han cambiado muchísimo. La forma de trabajar también. Hoy hablamos de Docker, cloud, APIs, ciberseguridad, DORA, IA, observabilidad, resiliencia y proveedores críticos.

Pero hay algo que viene de aquella etapa inicial y sigue estando ahí.

La necesidad de entender.

No me basta con que algo funcione. Quiero saber por qué funciona, qué depende de qué, dónde puede fallar, cómo se recupera y qué pasa si lo llevas al límite.

Por eso sigo tocando tecnología. Por eso tengo homelab. Por eso me gusta probar herramientas, romper cosas en entornos controlados, leer logs, mirar configuraciones y documentar lo aprendido.

Porque cuanto más responsabilidad tienes sobre tecnología, más importante me parece no quedarte solo en la presentación, en el dashboard o en la promesa comercial.

Al final, aquel camino desde BASIC hasta el reversing me enseñó una forma de pensar:

si quieres decidir bien sobre tecnología, primero tienes que entenderla de verdad.

Y esa idea todavía me acompaña.

Este artículo abre una serie más personal sobre mi historia técnica. En el siguiente seguiré con aquella forma de aprender: manuales, pruebas, errores y muchas horas entendiendo cómo funcionaban las cosas antes de que Internet te lo resolviera todo.

Fuentes y contexto histórico

Artículos relacionados

Deja un comentario