Llevo algo más de un año impartiendo el Ciclo Formativo de Grado Superior de Diseño de Aplicaciones Multiplataforma en PratFP. Ha sido un proceso de aprendizaje intenso, no solo para los alumnos sino para mí.
Lo que más me ha sorprendido es la brecha entre lo que la teoría pedagógica dice sobre cómo se aprende a programar y lo que sucede realmente en el aula cuando te enfrentas a 25 personas con niveles, motivaciones y estilos cognitivos completamente distintos.
El problema con la enseñanza expositiva de la programación
La programación se enseñó durante décadas de la misma manera: primero conceptos (variables, tipos, estructuras de control), luego sintaxis, luego ejercicios. Es el modelo del libro de texto, y tiene una lógica interna coherente.
El problema es que aprenderlo así se parece mucho a aprender a nadar leyendo un libro antes de entrar al agua. El conocimiento declarativo (“sé qué es un bucle for”) y el procedimental (“puedo usar un bucle for para resolver un problema que no había visto antes”) son cosas diferentes, y la brecha entre ambos es donde se pierden la mayoría de los estudiantes.
Lo que cambié
Empecé el curso con proyectos desde la primera semana. No pequeños ejercicios aislados, sino problemas reales con contexto: “Hay que construir una aplicación que gestione el préstamo de materiales del gimnasio del centro.” Los conceptos se introdujeron en el momento en que eran necesarios para avanzar en el proyecto.
El resultado fue desconcertante al principio. Los alumnos se bloqueaban, pedían más explicaciones, se sentían inseguros. Pero algo diferente empezaba a pasar: las preguntas que hacían eran mejores. En lugar de “¿qué es la herencia?”, preguntaban “¿cómo hago para que esta clase tenga los métodos de aquella otra?”.
Esa diferencia es fundamental. La segunda pregunta emerge de un problema que el alumno está intentando resolver. La respuesta tiene contexto, tiene aplicabilidad inmediata, y tiene una forma de ser verificada: ¿funciona el código o no funciona?
Las tres palancas que más han importado
1. Error-driven learning: En lugar de presentar el código correcto primero, muestro código con errores y dejamos que los alumnos los identifiquen. Leer y debuggear código ajeno es una habilidad que el mundo laboral exige pero que pocas veces se enseña explícitamente.
2. Retrospectivas breves: Los últimos 10 minutos de clase, pregunto: “¿Qué fue difícil hoy?” y “¿Qué es lo más interesante que aprendiste?”. Las respuestas ajustan las siguientes clases en tiempo real.
3. Pair programming estructurado: No libre (“trabaja con quien quieras”), sino con rotaciones deliberadas que mezclan niveles. El alumno más avanzado que explica algo lo entiende mejor; el que está atascado ve un modelo mental diferente al suyo.
Lo que sigo sin resolver
La evaluación. El sistema de calificaciones de la FP está diseñado para evaluar resultados, no procesos. Un alumno que comete errores productivos, los identifica y los corrige está aprendiendo mejor que uno que entrega el ejercicio correcto sin haber entendido por qué funciona. Pero el sistema de notas no distingue entre ambos.
Es el problema pedagógico en el que estoy trabajando ahora. Todavía no tengo una solución elegante.
