Técnicas de estudio

Cómo estudiar programación: leer código no es practicar

20 octubre 2026 · 9 min de lectura

Hay una experiencia que reconoce casi todo el que estudia programación: sigues un tutorial de tres horas, entiendes cada línea mientras la escribe el profesor, cierras el portátil con la sensación de haberlo pillado, y al día siguiente te sientas delante de un editor en blanco y no sabes ni por dónde empezar. No es que se te dé mal ni que te falte base. Es que programar es una destreza, no un temario, y las destrezas no entran leyendo. Entran produciendo, fallando y arreglando, que es exactamente la parte que los tutoriales te ahorran.

Programar no se aprende leyendo, se aprende escribiendo

Cuando estudias historia o derecho, el objetivo es poder reproducir un contenido y razonar sobre él. En programación el objetivo es que tu cabeza y tus manos resuelvan un problema que no has visto antes, con la documentación abierta si hace falta. Son cosas distintas y se entrenan distinto. Leer código ajeno bien escrito sirve —igual que leer buena prosa si quieres escribir—, pero no sustituye a escribirlo. El examen, y después el trabajo, te van a pedir lo segundo.

La trampa es que leer da una sensación de progreso muy convincente. Entiendes el bucle, entiendes la función recursiva, asientes. Reconocer una solución cuando la tienes delante y ser capaz de construirla desde cero son habilidades separadas, y la primera no arrastra a la segunda. Aquí, al menos, se nota antes que en otras asignaturas: el código funciona o no funciona, y no hay medio punto por tenerlo claro mentalmente.

El error de seguir tutoriales con la solución delante

El formato tutorial —el vídeo, los apuntes con el ejemplo resuelto, el repositorio con la solución— está diseñado para que nada falle. Y como nada falla, no practicas nada de lo que de verdad cuesta. Tecleas lo que ves, compila, funciona, siguiente. Esa sesión de tres horas te deja un proyecto bonito y cero capacidad nueva. Si tuvieras que rehacerlo mañana sin el vídeo no saldría, y ese es el mejor test de si una sesión ha servido para algo.

La versión útil del mismo tutorial cuesta más tiempo y vale mucho más: míralo entero una vez sin tocar el teclado, cierra todo, y reconstruye el ejemplo de memoria en un fichero vacío. Vas a atascarte. Ese atasco es la sesión de estudio: ahí está, señalado, lo que no sabías. Consulta lo mínimo para desbloquearte, apunta qué te faltaba y sigue. Lo que has peleado se queda; lo que has copiado, no.

Separa dos cosas distintas: conceptos y destreza

Una asignatura de programación tiene dos capas, y mezclarlas es lo que hace que estudiar parezca imposible. La capa de conceptos es la que sí se parece a estudiar normal: qué es un puntero, cómo funciona el paso por referencia, qué coste tiene una búsqueda binaria, qué hace exactamente el recolector de basura. Eso entra en la parte teórica, se olvida como cualquier otra cosa y se mantiene con repaso espaciado y preguntándote a ti mismo, no releyendo las transparencias.

La capa de destreza es escribir, compilar, equivocarte y arreglarlo, y solo se entrena con las manos y con volumen. La consecuencia práctica es que necesitas dos tipos de sesión en la semana: sesiones cortas de conceptos, con preguntas sobre lo que creías claro, y sesiones largas de teclado, donde lo único que cuenta es cuántos problemas has resuelto tú. Para las primeras, las reglas son las mismas que en cualquier asignatura y están en active recall.

Si para rehacer mañana lo que hiciste hoy necesitas volver a abrir el tutorial, hoy no has estudiado: has transcrito.

Depurar es la asignatura que nadie te da

Ninguna guía docente dice «tema 0: leer mensajes de error», y es lo que más separa a quien avanza de quien se atasca. El principiante ve una traza roja de veinte líneas, siente que algo ha explotado y vuelve al principio a cambiar cosas al azar. El mensaje, casi siempre, dice literalmente el fichero, la línea y qué esperaba encontrar. Leer el error completo, despacio, es la técnica más rentable que hay en esta asignatura y no cuesta nada aprenderla.

El método aburrido funciona: lee el error entero, localiza la línea exacta, inspecciona el valor que crees que tiene la variable y comprueba si es el que crees. Casi todos los fallos salen de ahí, de una variable que no contiene lo que das por hecho. Cambiar código a ciegas hasta que compile te saca del apuro una vez, pero no deja nada detrás. Una hora depurando con método vale más que tres de vídeo.

Cómo se estudia para un examen de programación

Lo primero es averiguar en qué formato examinan, porque cambia el plan entero. Un examen en papel, escribiendo código a mano, penaliza cosas que el ordenador te perdona: sintaxis exacta, nombres de funciones, llaves cerradas. Si es tu caso tienes que practicar a mano, aunque se te haga rarísimo, porque escribir sin autocompletado es otra actividad. Si es en ordenador y sin internet, practica exactamente así: entorno limpio, sin buscador, con la documentación que te vayan a permitir.

Después, simulacros. Coge los exámenes de años anteriores, siéntate a reloj y resuélvelos de una sentada sin mirar nada. Es la única forma de detectar las dos cosas que suspenden estos exámenes y que no se ven estudiando: que vas lento y que te falta un concepto concreto. Y clasifica los problemas por tipo —recorrer una estructura, recursión, ficheros, clases— porque los enunciados cambian cada año pero los tipos se repiten, igual que en matemáticas.

La constancia importa aquí más que en otras asignaturas

Programación castiga el atracón más que ninguna otra asignatura. Siete horas de un sábado te dejan un proyecto a medias y la cabeza frita; una hora al día, seis días, te deja seis arranques desde cero, que es justo lo que el examen te va a pedir. Y la destreza se oxida rápido: dos semanas sin tocar el teclado y vuelves a dudar de la sintaxis que tenías dominada. Poco y casi todos los días es, aquí, literalmente mejor que mucho y de golpe.

La otra razón para repartirlo es que los problemas se resuelven solos mientras no los miras. Te atascas, lo dejas, y a la mañana siguiente ves el fallo en dos minutos. Eso solo pasa si has parado a tiempo en vez de insistir cuatro horas a las dos de la madrugada, cuando cada intento es peor que el anterior. Cerrar el portátil con un problema sin resolver y apuntarlo para mañana no es rendirse: suele ser la decisión más eficiente de la sesión.

Para que ese «poco y casi todos los días» no dependa de la fuerza de voluntad, el plan tiene que estar escrito en algún sitio. Es lo que puedes hacer con una app como Aprofy: das de alta la asignatura con sus temas —estructuras, recursión, ficheros, orientación a objetos— y los marcas cuando eres capaz de resolverlos sin ayuda, no cuando los has leído. El timer registra cada sesión sin que la anotes, así que al final de la semana las estadísticas de horas te dicen cuánto has programado de verdad, que casi nunca coincide con lo que recordabas. Puedes guardar la fecha del examen con su countdown y verla en el widget de la pantalla de inicio, montar el plan del día a partir de plantillas y poner recordatorios en tus días de estudio. La racha se encarga de la parte difícil, que es sentarse también el día que no apetece, y las notas de las prácticas y los parciales caben en el boletín de notas.