Hay una pregunta que muchos padres se hacen tras matricular a su hijo en un curso de programación: "se lo pasa bien, ¿pero está aprendiendo de verdad?". La pregunta correcta no es ésa. La pregunta correcta es: ¿qué puede mostrarme que ha construido por sí mismo, sin la plataforma abierta delante?
Si la respuesta es "ehh, no sé exactamente, hicimos un juego de Minecraft pero no me lo puedo enseñar", el curso ha hecho bien una cosa (entretener) y otra peor (enseñar). No son lo mismo, y en este mercado se confunden con demasiada frecuencia.
Por qué el engagement no basta
Que un niño salga contento de una clase es buena señal, no mala. El problema aparece cuando el contento es lo único que tienes. La investigación sobre aprendizaje multimedia es bastante consistente en dos puntos incómodos: los estudiantes no perciben siempre como "mejor" la modalidad que más les enseña, y los llamados "detalles seductores" —música pegadiza, animaciones llamativas, personajes carismáticos— pueden perjudicar el aprendizaje aunque aumenten la satisfacción.
Esto importa porque los cursos online están comercialmente incentivados a maximizar lo primero. Un curso que entretiene mucho genera buenas reseñas, retiene suscripciones y trae al niño la semana siguiente. Un curso que enseña bien hace lo mismo, pero también atraviesa momentos incómodos: el niño se atasca, frunce el ceño, quiere abandonar. Si el curso ha eliminado todas las fricciones, probablemente también ha eliminado el aprendizaje.
La revisión de la Fundación Raspberry Pi sobre cómo enseñar programación en escuelas lo plantea con claridad: el aprendizaje significativo se construye sobre proyectos donde el alumno crea algo concreto, encuentra problemas y los resuelve. No sobre tutoriales paso a paso donde "todo funciona a la primera".
Los tres outcomes que importan
Una forma útil de evaluar es preguntarte qué tres cosas deberían cambiar en tu hijo si está aprendiendo de verdad. Si no cambia ninguna, el curso es entretenimiento con disfraz educativo.
1. Autonomía creciente
Tu hijo empieza copiando plantillas. Eso es normal. En unas semanas debería pasar a modificarlas con intención —cambiar colores, ajustar reglas, añadir un personaje propio—. En unos meses, a diseñar un proyecto desde cero con guía decreciente. Si tres meses después sigue replicando exactamente lo que dice el profesor, no está aprendiendo a programar: está aprendiendo a usar la plataforma.
2. Retención de unas semanas a otras
Pídele que retome un proyecto que hizo hace dos o tres semanas y le añada algo. Si necesita empezar de cero porque "no se acuerda de cómo era", lo que aprendió era memoria de corto plazo. Un buen curso deja huella semanas después, no solo durante la sesión.
3. Transferencia a contextos nuevos
Si ha hecho un juego con bucles en Scratch, ¿puede aplicar la idea de bucle a una historia interactiva diferente? ¿Puede explicar qué hace un condicional fuera de los ejemplos que le pusieron en clase? Sin transferencia no hay concepto: solo hay reconocimiento de patrones específicos.
Estos tres outcomes vienen del marco de Brennan y Resnick (MIT Media Lab), que distingue entre conceptos computacionales (bucles, variables), prácticas (depurar, iterar) y perspectivas sobre uno mismo como creador. Los tres están conectados, y los tres se pueden observar en casa con preguntas concretas.
Cómo se ve un buen curso por dentro
La evidencia favorece una combinación específica: construcción activa con guía fuerte para principiantes. Ni clase pasiva (ver y reproducir), ni descubrimiento libre (déjale el ordenador y a ver qué pasa). En medio: el niño construye, sí, pero con andamiaje. El profesor o la plataforma le da estructura, le hace predecir antes de ejecutar, le ayuda a leer código antes de pedirle que lo escriba.
La depuración merece atención especial, porque es donde más se separa un buen curso del resto. Los errores no son interrupciones del aprendizaje: son el aprendizaje. Un curso que diseña sus proyectos para que "todo funcione a la primera" está, paradójicamente, robándole al niño la práctica cognitiva más valiosa de la programación. La pregunta "¿por qué no funciona?" es la madre de todas las preguntas técnicas, y un buen curso la provoca con intención.
En la práctica, un buen curso típicamente:
- Pide al niño que prediga qué hará un trozo de código antes de ejecutarlo.
- Le hace modificar proyectos existentes antes que crear desde cero.
- Cuando algo falla, le da pistas para depurar; no le arregla el error él.
- Le pide explicar a alguien —familia, compañero— lo que ha hecho y por qué funciona.
- Tiene una progresión visible: empieza fácil, sube de complejidad, retoma conceptos previos.
6 preguntas para hacer al proveedor antes de pagar
Estas preguntas no buscan respuestas concretas: buscan medir la precisión con la que el proveedor responde. Si te responde con generalidades —"aprenden muchísimo", "se motivan", "depende del niño"— ya tienes información.
- Resultado. "¿Qué podrá hacer mi hijo por sí mismo en 8 semanas que hoy no puede hacer?"
- Autonomía. "¿Cuándo deja de copiar plantillas y empieza a diseñar proyectos con decisiones propias?"
- Retención. "¿Cómo comprobáis lo que recuerda un mes después, no solo al final de la clase?"
- Errores. "Cuando un niño se atasca, ¿cómo lo trata el profesor? ¿Le da pistas, modela una solución, o le arregla el código?"
- Evaluación. "¿Me podéis enseñar un ejemplo concreto de feedback que dais a las familias?"
- Revisión. "Si a las 6-8 semanas no vemos autonomía creciente, ¿qué haríais distinto?"
Los proveedores que optimizan aprendizaje responden con concreción: rúbricas, ejemplos de proyectos reales, hitos por edad, criterios para pasar de un nivel a otro. Los que optimizan activación comercial responden con marketing.
Red flags para descartar rápido
Hay señales que permiten descartar un curso en cinco minutos sin haber pagado:
- "Tu hijo creará apps profesionales en X semanas." Falso. Programar es lento; cualquier promesa de fluidez en tiempos cortos es marketing.
- "Lecciones completadas" como único indicador. Es una métrica de actividad, no de aprendizaje. Mide que tu hijo usa la app, no que aprende.
- Currículum que junta Scratch + Python + IA + ciberseguridad + Roblox + Minecraft en un mismo paquete sin progresión. Ancho de un dedo, hondo de un milímetro.
- Profesorado opaco. Si no puedes ver quién enseña, qué experiencia tiene con niños y cómo se forma, asume que no es la prioridad del proveedor.
- La clase de prueba consiste en ver y seguir. Si tu hijo no toma decisiones, no se atasca y no depura nada durante la prueba, no espera que pase mágicamente en la clase 5.
- El niño sale entusiasmado, pero no puede explicarte lo que hizo. Probablemente disfrutó de un vídeo bien producido. No es lo mismo que aprender.
Cuándo encaja Learning Buddies
Por todo esto, Learning Buddies está construido alrededor de proyectos propios, no de tutoriales paso a paso. El niño construye algo que es suyo, decide qué cambiar, se atasca, depura, y puede mostrarte lo que ha hecho fuera de la plataforma. No prometemos fluidez en cuatro semanas porque no es honesto; sí ofrecemos el primer proyecto gratis, para que veas lo que tu hijo crea antes de decidir nada. La filosofía la explicamos más en detalle en Para padres.
Como vimos en la entrada anterior sobre a qué edad empezar a programar, nuestra ventana es a partir de los 8 años, con un peso especial entre los 9 y los 14. Eso encaja con la apuesta por proyectos creativos: antes de esa edad, el niño necesita más juego tangible y menos pantalla guiada.
Checklist mental de 30 segundos
Si tuvieras que evaluar cualquier curso —el actual, uno que estás considerando, el que recomienda una amiga— con tres comprobaciones, serían éstas:
- ¿Puede tu hijo mostrarte un proyecto que hizo, sin la plataforma abierta? Si no, no es suyo.
- ¿Puede explicártelo con sus palabras? Si no, no lo entendió.
- Si hace dos semanas vio un concepto, ¿sigue pudiéndolo aplicar? Si no, no lo aprendió.
Si responde sí a las tres, el curso está funcionando, le entretenga o no. Si responde no a alguna, lo demás —los avatares, los puntos, los certificados, los personajes con licencia— es decoración.
Fuentes
- Raspberry Pi Foundation. Teaching programming in schools: a review of approaches and strategies. raspberrypi.org
- Brennan, K. & Resnick, M. (2012). New frameworks for studying and assessing the development of computational thinking. MIT Media Lab — marco de conceptos, prácticas y perspectivas computacionales.
- Sentance, S., Waite, J. & Kallia, M. PRIMM: Predict, Run, Investigate, Modify, Make — marco pedagógico de leer-modificar-crear en programación.
- Mayer, R. E. Multimedia learning principles. Cambridge University Press — investigación sobre detalles seductores y aprendizaje activo frente a pasivo.
- Code.org. Computer Science Fundamentals — currículo con rúbricas y evaluación formativa. code.org
- OECD. The State of the Field of Computational Thinking in Early Childhood Education. oecd.org