Llevar la industria al aula: lo que he aprendido en mi primer año como docente de FP
13 años en la industria, un máster de Formación del Profesorado y cuatro grupos distintos: JavaScript, Java, Kotlin y Godot. Lo que nadie te cuenta sobre la brecha entre lo que se enseña y lo que se necesita.
En septiembre de 2025 entré por primera vez a un aula como docente.
No como ponente invitado de una hora que explica cómo es el mundo real y se va. Como profesor. Con un horario, un currículo oficial y cuatro grupos muy distintos entre sí: introducción al desarrollo web en JavaScript con alumnos de SMR de grado medio, programación orientada a objetos en Java con primero de DAW y DAM, y desarrollo de aplicaciones móviles y videojuegos con Kotlin, Jetpack Compose y Godot.
Llevaba trece años en esa industria. He programado en Java en entornos de producción. He trabajado con servicios backend, con AWS, con arquitecturas distribuidas. Creía que eso me daba una ventaja considerable.
La tenía, pero no donde esperaba. Y las cosas que no sabía eran más de las que imaginaba.
Esto es lo que he aprendido en este primer año.
La brecha es real. Y es más grande de lo que pensaba.
Antes de empezar, tenía una hipótesis: la formación en FP está algo desactualizada, los contenidos del currículo no son exactamente lo que pide la industria, pero las bases son sólidas.
Me equivocaba en la dirección de la hipótesis.
Las bases no siempre son sólidas. Y la desactualización no es “algo”. Es estructural.
No es culpa de los docentes. Es el resultado de un sistema donde el currículo se diseña con años de retraso respecto a la industria, donde los ciclos de actualización son lentos, y donde muchos profesores llevan tiempo sin trabajar directamente en empresas tecnológicas.
El resultado: hay alumnos que terminan un ciclo de DAW sin haber visto Git en un contexto real de equipo. Que no han hecho un pull request. Que no han depurado un error mirando los logs de una consola de producción. Que no saben qué es una code review ni por qué existe.
Y hay alumnos que aprenden Java como si fuera un lenguaje de relleno obligatorio, sin entender que los principios que hay detrás —encapsulación, herencia, polimorfismo, SOLID— son los mismos que van a necesitar en Kotlin, en TypeScript, en cualquier lenguaje orientado a objetos que usen en su carrera.
No porque sean malos estudiantes. Sino porque nadie les ha dado el contexto que conecta lo que aprenden con lo que van a hacer.
Lo primero que cambié: el contexto de cada ejercicio
El currículo oficial es claro en qué hay que enseñar. Pero no siempre es claro en por qué.
Y el por qué es exactamente lo que diferencia a alguien que sabe hacer algo de alguien que entiende lo que está haciendo.
En la industria, nadie te pide que “implementes una función que recorra un array y devuelva los elementos pares”. Te piden que resuelvas un problema de negocio concreto, con un contexto, con unas restricciones y con usuarios reales al otro lado.
Así que empecé a reencuadrar los ejercicios.
En lugar de “crea un formulario de registro con validación”, el ejercicio se convierte en: “Eres el desarrollador frontend de una startup. Tu PM acaba de decirte que el 40% de los usuarios abandonan el registro en el paso 2. Tienes que identificar los problemas del formulario actual y proponer una versión mejorada.”
El resultado técnico es casi el mismo. Pero el contexto cambia completamente cómo los alumnos se relacionan con el problema. Dejan de buscar la respuesta correcta y empiezan a tomar decisiones.
Eso es lo que hace un desarrollador profesional cada día.
Git no es una herramienta. Es una forma de trabajar.
Esto me sorprendió más de lo que debería.
Git se enseña en los ciclos. Hay módulos donde aparece, hay ejercicios donde se usa. Pero en muchos casos se enseña como una herramienta de guardado avanzado: git add, git commit, git push. El ciclo mínimo para tener el código en algún sitio.
Lo que no se enseña —o se enseña tarde y con poco contexto— es Git como práctica de equipo.
Ramas con nombre semántico. Pull requests con descripción útil. Code review como conversación, no como validación. Resolución de conflictos cuando dos personas trabajan en el mismo archivo. El flujo completo de: crear una rama, desarrollar, abrir un PR, recibir comentarios, incorporarlos, mergear.
Eso es el 80% de lo que hace un desarrollador en una empresa real. Y muchos alumnos llegan a su primer empleo sin haberlo practicado en un entorno simulado.
Este año introduje proyectos grupales con flujo de Git real en todos los grupos donde era posible: repositorios en GitHub, ramas por funcionalidad, pull requests obligatorios para mergear. La curva de aprendizaje fue empinada las primeras dos semanas. Después, era natural.
Lo mismo aplica en el módulo de videojuegos con Godot. Al principio los alumnos quieren resultados visuales rápido —sprites, movimiento, colisiones—. Pero si antes no entienden cómo organizar el código, cómo separar la lógica del juego de la presentación, acaban con proyectos que no pueden mantener ni ellos mismos. La estructura importa en un videojuego igual que en una aplicación bancaria. El dominio cambia; los principios no.
Lo que la industria no sabe hacer: explicar
Aquí viene la otra cara, la que cuesta más reconocer.
La industria asume que el conocimiento se transfiere por osmosis. Que si pones a un junior al lado de un senior, el junior aprende. Que si escribes código limpio, los demás aprenden a escribir código limpio. Que si documentas la arquitectura, los demás la entienden.
No funciona así.
Enseñar es una habilidad distinta de saber. Y la industria tecnológica en general tiene un déficit serio en esa habilidad.
He visto a ingenieros brillantes —algunos de los mejores desarrolladores con los que he trabajado— que eran incapaces de explicar por qué un patrón de diseño era mejor que otro sin entrar en tecnicismos que perdían al interlocutor en treinta segundos. No porque no lo supieran. Sino porque nunca habían tenido que construir el puente entre lo que ellos entendían intuitivamente y lo que alguien que no lo sabe necesita escuchar.
Dar clase me ha hecho mejor en eso. Mucho mejor.
Cuando tienes que explicar qué es un closure a alguien que lleva tres meses programando en JavaScript, no puedes decir “es una función que captura su entorno léxico”. Tienes que encontrar la analogía, el ejemplo concreto, el punto de anclaje en algo que ya conocen.
Cuando tienes que explicar la herencia en Java a alguien que hasta ayer programaba en procedural, o el sistema de nodos de Godot a alguien que nunca ha pensado en términos de grafos, el reto es el mismo: encontrar el puente entre lo abstracto y lo concreto sin perder la esencia del concepto.
Ese proceso —buscar la forma de que algo complejo se vuelva comprensible sin perder su esencia— es exactamente lo que necesita un arquitecto cuando defiende una decisión técnica ante un equipo que no comparte su mismo nivel de abstracción.
No son mundos separados. Son la misma habilidad en contextos distintos.
El error que cometí en el primer trimestre
Llegué con demasiada industria encima.
El primer mes quise enseñar todo lo que a mí me había costado años aprender. Clean Architecture en Java. Principios SOLID desde la primera semana. Inversión de dependencias antes de que nadie hubiera escrito un bucle completo.
Mis alumnos llevaban semanas programando por primera vez en su vida.
El resultado fue el esperado: sobrecarga cognitiva, desmotivación en algunos, y yo sin entender por qué no avanzábamos.
El problema no era el contenido. Era la secuencia. Y la secuencia en educación es todo.
Aprender a programar no es acumular conocimiento. Es construir modelos mentales encima de otros modelos mentales. Si saltas pasos, los modelos se caen. El estudiante memorizará la sintaxis pero no entenderá qué está haciendo ni por qué.
Tuve que reaprender algo que como desarrollador había interiorizado sin ser consciente de ello: todo conocimiento técnico tiene prerequisitos. Y si no los has establecido primero, estás construyendo sobre arena.
Ahora diseño las unidades hacia atrás: primero decido qué quiero que el alumno sea capaz de hacer al final. Luego identifico qué necesita saber para llegar ahí. Luego qué necesita saber para entender eso. Y así hasta llegar al punto de partida real.
Es casi lo mismo que hacer el diseño de una arquitectura de software. Trabajar de atrás hacia adelante. Entender el destino antes de decidir el camino.
Lo que sigue pendiente
Hay cosas que no he resuelto todavía.
El currículo oficial es rígido. Hay módulos con contenidos que ya no son relevantes o que necesitan actualizarse, y no siempre es posible reemplazarlos. Hay una tensión constante entre cumplir con lo que pide la programación didáctica y dar a los alumnos lo que realmente necesitan para trabajar.
También hay una brecha de expectativas entre lo que los alumnos creen que necesitan (aprender a usar herramientas concretas, frameworks populares, lo que aparece en las ofertas de trabajo) y lo que realmente les va a dar ventaja a largo plazo (pensamiento computacional, capacidad de aprender por su cuenta, hábitos de trabajo profesional).
Convencerles de que los fundamentos importan más que el framework de moda es una conversación que tengo casi cada semana. Y la entiendo: ellos ven las ofertas de trabajo, ven que piden React o Angular o Flutter, y quieren aprender exactamente eso. La presión es real.
Lo que intento transmitirles es que quien aprende Java bien tiene la mitad del camino hecho para aprender Kotlin. Quien entiende la orientación a objetos de verdad puede moverse entre lenguajes. Quien solo aprende una herramienta concreta depende de que esa herramienta siga siendo relevante.
Pero el desarrollador que aprende a pensar antes que a teclear es el que en cinco años está liderando equipos. El que solo aprende herramientas es el que en cinco años está aprendiendo la siguiente herramienta.
Eso también lo digo en clase. Que lo asimilen es trabajo de todo el año.
Por qué este año merece la pena
Con todo lo anterior, hay algo que no esperaba con la intensidad que lo he encontrado: el impacto directo de enseñar bien es mucho más visible que el impacto de diseñar bien una arquitectura.
Cuando defines la arquitectura de un sistema, el efecto es largo y distribuido. Hay equipos que trabajarán mejor, código que será más mantenible, decisiones que resultarán más fáciles. Pero no lo ves de forma inmediata. El feedback tarda.
Cuando ves a un alumno que lleva semanas sin entender la programación orientada a objetos y de repente algo encaja — eso es inmediato. Y deja huella en los dos sentidos.
Quiero seguir haciendo las dos cosas. No creo que sean incompatibles. De hecho, creo que son necesariamente complementarias: la industria necesita docentes que sepan de lo que hablan, y la academia necesita que la industria no sea un mundo aparte.
Este blog es, en parte, el espacio donde voy a intentar que esa conversación suceda.
Si eres docente de FP o quieres serlo, si eres una empresa que no entiende por qué sus juniors llegan sin ciertos hábitos, o si simplemente tienes opinión sobre cómo debería funcionar la formación técnica en España — cuéntame. Las mejores conversaciones de este año han empezado exactamente así.