Comenzar en el mundo de la programación puede llegar a ser muy complicado, especialmente si no se elige un lenguaje adecuado (podríamos discutir largo y tendido sobre este tema), no se tiene suficiente capacidad de abstracción o, simplemente, se explica mal. Es por esto que voy a presentar un planteamiento basado en el modelo de las 5E para que el alumnado de TIC II de 2º de Bachillerato pueda empezar a diseñar sus primeros programas (pese a que no me guste plantear una solución genérica sin contextualizar al grupo, pues, no creo en los gurús que afirman que algo funciona para absolutamente todos los grupos de, en este caso, 2º de Bachillerato).
Pero… ¿Qué es el modelo de las 5E?
El planteamiento, por tanto, se basa en “repartir” esas 5E en sesiones, con el objetivo de que todos los alumnos y alumnas sepan, al menos:
Qué es un programa.
Cómo se diseñan e implementan programas sencillos.
Cómo se depuran programas sencillos.
Para qué sirve programar.
Por qué deberían aprender a programar (aparte de para aprobar la asignatura).
Considero que esas son las preguntas que, como mínimo, debería saber responder cualquier alumno/a al terminar el bloque de programación de TIC II.
Enganchar
Esta parte es complicada. Recordemos que una clase de 2º de Bachillerato está compuesta por “Gen Zetters”, personas que necesitan muchos estímulos, variados, y de corta duración. Al fin y al cabo, es a lo que están acostumbrados. Es por eso que plantearía una clase lo más interactiva posible (empiezo a sonar como un gurú), basada en preguntas y respuestas y relacionando el mundo de la programación con temas cercanos a ellos… Es cierto que la programación ha sido muy importante para que los gigantescos sistemas bancarios sobre los que se apoya nuestra sociedad funcionen… ¿Pero qué tal si presentamos una versión más amigable de la programación a chavales de 17 años? Se me ocurre hablarles de Fortnite, del algoritmo de TikTok, o de cómo las ingenieras de Facebook (o Meta) han desarrollado redes neuronales tan inteligentes que conocen mejor sus gustos que sus propios padres. También podemos hablar de que aprender a programar desarrolla la capacidad de abstracción y procesamiento lógico, ayuda a organizar mejor las ideas… Se trata de enganchar al alumnado, darles motivos por los que está bien que aprendan (un poquito) sobre programación y evitar que se pregunten lo que nos hemos preguntado todos en algún momento: “y esto a mí… ¿Para qué me sirve?”. Una sesión sería suficiente para presentar el bloque de programación y, con suerte, gran parte del alumnado saldría de la clase ilusionado porque va a empezar a entender cómo funcionan los sistemas informáticos con los que convive a diario.
Explorar
“¿Alguna vez os habéis planteado cómo funciona una calculadora?” Este sería el primer reto, analizar y arreglar el código con “bugs” de una sencilla calculadora (suma, resta, multiplicación y división) en Python. Sin haberles explicado nada, por parejas, deberían ser capaces de “depurar” el código de la calculadora, que está mal implementado: en lugar de hacer una operación hace otra (la suma, resta; la resta; multiplica, la multiplicación, divide; la división, suma). En una sesión deberían haber terminado.
Explicar - Elaborar - Evaluar - Explicar - Elaborar - Evaluar…
El código de la calculadora tenía variables, funciones, condicionales… Que probablemente ya hubieran visto en otros lenguajes de programación como Scratch (aprendizaje constructivista). Al inicio de esta fase (explicar), también interactiva y en la que participaría todo el grupo, el docente solucionaría el problema poco a poco preguntando a distintas personas de la clase. ¿Y esto del “if” qué es? ¿Aquí qué signo matemático tendríamos que poner? ¿Y por qué hay una función llamada “sumar” que recibe dos “parámetros” pero utiliza el signo de restar? La idea es que sean capaces de explicar lo que han visto y que, progresivamente, vayan adquiriendo los tecnicismos relacionados con los lenguajes de programación.
El bloque de esta sección está en forma de bucle (secuencial e iterativa) puesto que pienso que no tiene sentido explicar todo, soltarles todas las tareas de golpe y evaluar todo al final. Planteo una metodología en la que primero se explica una pequeña parte (e.g. uso de variables), se muestran ejemplos, se pide que individualmente resuelvan un par de ejercicios en relación a esa parte y, mientras tanto, se evalúa (aunque también se evalúa al final). Considero que para aprender programación es necesario tener conocimientos sobre ciertas partes básicas antes de seguir. Es decir, una persona que no sepa cómo funcionan las variables no va a entender cómo funcionan los condicionales que usan variables. Como docentes, al explicar programación, debemos asegurarnos de que nadie se pierde en la base si queremos que siga alineado con el nuevo contenido que queramos que aprenda.
Estas tres fases, por tanto, se llevarán a cabo mediante:
Una pequeña explicación conceptual.
Conceptos llevados a la práctica por el profesor mediante ejemplos.
Conceptos llevados a la práctica por los alumnos mediante la resolución de ejercicios similares a los ejemplos.
Evaluación de la situación de la clase (quién entiende qué/quién no entiende qué).
Finalmente, al terminar todos los conceptos (y, por tanto, todos los ejemplos y ejercicios), cada alumno deberá enviar al profesor los códigos fuentes de los ejercicios para una evaluación final. 6 sesiones deberían ser suficientes para llevar a cabo estas tres fases.
Como autoevaluación, considero que el haber diseñado esta herramienta/metodología de enseñanza-aprendizaje ha hecho que me dé cuenta de que es complicado aprender a programar, pero también puede llegar a ser complicado enseñar a programar (especialmente si quieres hacerlo bien). A la hora de diseñar ejemplos y ejercicios, es difícil buscar temáticas que les puedan resultar atractivas/interesantes sin complicar mucho el problema. Se podría hacer uso de APIs (de TikTok, de Fortnite…), pero añadirían una complejidad que podría propiciar que muchos de los alumnos no entendieran los ejemplos y/o no supieran resolver los ejercicios. Sin embargo, y como he dicho al inicio, no todo vale para todos los grupos, por lo que la mejor forma de evaluar esta metodología sería aplicándola.
Me parece muy interesante la manera que propones de "engancharles" a la actividad hablándoles de Tik Tok o del Fornite, temas que sin duda les van a resultar interesantes.
Me pregunto si en la parte de exploración sin ningún conocimiento previo serán capaces de "depurar" el código (lo digo desde el pleno desconocimiento de programación).
En definitiva me parece una propuesta interesante la que haces y coincido completamente contigo en la reflexión final, la mejor forma de evaluar nuestro diseño es llevándolo a la práctica.
Creo que la metodología que propones para enseñarles a programar, dejar que primero investiguen con un programa hecho de manera errónea, es interesante, porque favorece la independencia y la creación de su propio aprendizaje, pero creo que habría que estar muy atentos cómo docentes para corregir posibles errores que se produzcan en la comprensión de los conceptos.
Como dices, la base es muy importante y si la quieren mal durante el aprendizaje autónomo habrá que detectarlo y corregirlo.
La descripción de esta herramienta de enseñanza mejoraría si detallaras más qué cómo propones darles motivos para que aprendan a programar.
También echo en falta un diseño más detallado de las fases del ciclo Explicar - Elaborar - Evaluar y la reflexión sobre la adecuación de la actividad de aprendizaje a los objetivos que te propones, que deberían tener relación con los objetivos curriculares de 2º Bto. En el Pensadero expones que te has encontrado con una dificultad, pero no explicas si las has superado o qué te falta para hacerlo.
Enhorabuena Raúl!
Me parece una metodología muy apropiada para aprender a programar! Creo que puede suscitar ese interés y esa orientación al dominio del lenguaje. Se notan tus ganas de transmitir!