Entradas del Blog

Una vez has aprendido un lenguaje tienes facilidad para aprender otros, sólo hay que fijarse en la sintaxis propia de cada lenguaje y desde ahí construir un aprendizaje.

Mi consejo, en caso de empezar de cero y no querer acudir a uno de los típicos programas enfocados a aprender a programar (Scratch, por ejemplo), sería acudir a Python. Sus estructuras de código son sencillas y eso acelera el aprendizaje. Además, se trata de un lenguaje multipropósito que es usado en el ámbito profesional. Si la parte gráfica es un problema podéis empezar con Python en Processing.

Lo importante es esforzarse en enseñar en profundidad y no en extensión. No sirve de nada enseñar 5 o 6 lenguajes y no utilizar ninguno realmente.

Bajo mi punto de vista trabajar de forma magistral con un grupo amplio de personas que tienen delante un ordenador es un infierno. No le desearía ni a mi peor enemigo tratar de avanzar al mismo ritmo con 30 alumnos adolescentes y una pantalla en sus manos. Es cierto que tiene que existir una introducción guiada y algo más magistral, pero el error está en centralizar esa introducción en una única persona y un único tiempo.

Personalmente creo que deberían trabajar los alumnos de forma individual, por parejas o en el peor de los casos por trios, compartiendo un ordenador. Si no es posible hacerlo así el proceso se dificulta bastante y habrá que pensar en un método que haga que todos los alumnos tengan sus momentos de desempeño con el ordenador.

Mi consejo es que se trabaje por retos o pequeños proyectos tras una primera fase de aprendizaje de las bases y aspectos relevantes. Para ello prepararía un guión de unos primeros ejercicios explicando la base en texto, vídeo o cualquier otro medio. Hay que conseguir que cada uno de los alumnos o grupos puedan resolver sus dudas y avanzar a su ritmo. Es un hecho que el medio educativo habla mucho de favorecer diferentes ritmos de aprendizaje pero en este caso es indispensable.

Una posible forma de trabajar sería:

- Los grupos de trabajo tendrán un pequeño guión inicial a seguir para entender los conceptos básicos. Digamos que sería como el tutorial inicial de cualquier videojuego antes de lanzarse a la aventura.

- Tras completar el “entrenamiento” cada alumno o grupo tendrá una serie de retos que tendrán que ir resolviendo a su ritmo. Desde el principio se dejará claro que cantidad mínima de retos habrá que superar pero no se pedirá un número a partir de ahí, sino que se buscará que cada grupo avance a su ritmo.

- Lo idóneo sería que los retos tuviesen una resolución abierta, de forma que cada grupo pueda acometer su resolución de diferentes maneras y favorecer la riqueza de soluciones en el aula. Esto no quiere decir que no se pueda permitir que todos lo hagan de la misma forma, sino que no se enfoque a la solución directamente sino que se plantee un problema que haya que resolver y el cómo hacerlo quede más a la elección de cada alumno o grupo de trabajo.

- Los retos deberán pedir diferentes cosas, no siempre un script, de forma que haya que ir presentando diferentes soluciones (un diagrama de flujo, un programa comentado, un script…).

- Los alumnos deben tener una webgrafíadonde puedan acudir a solucionar todos sus problemas, el profesor debe dejar de ser la figura a la que acudir para resolver dudas. Es importante trabajar en ello y, al principio, será un poco desastroso porque suelen estar muy acostumbrados a preguntar sin pararse a intentar buscar la solución. Por ello tenemos que recoger una serie de páginas con ayudas para el lenguaje que elijamos, tutoriales de gente que enseñe cómo resolver problemas, etc. En última instancia estará la búsqueda por internet para intentar resolver un problema. De conseguirlo estarán aprendiendo mucho más que a programar.

- Para evitar que pregunten por preguntar se puede dar una serie de “créditos” a cada grupo y si te hacen una pregunta que está resuelta en el material que les has entregado les quitas créditos por resolverla, y si no les quedan créditos no pueden preguntar más. Evidentemente, si la pregunta es inteligente, no está resuelta o es complicado que lo consigan solos no tendremos que quitarle créditos. Una opción más compleja sería que pusiesen un fundo por grupo de trabajo (algo simbólico, un euro en monedas de 10 céntimos, por ejemplo) y que por cada pregunta tengan que pagar una cantidad. Lo recopilado por preguntas absurdas se puede destinar a material para el aula o algo así...

Es importante no centrarse en el acto en sí de programar sino favorecer el aprendizaje de la utilidad de la programación. Por ello los retos deben cumplir unos aspectos básicos para aprender a ubicar la programación en un ámbito y no simplemente aprender a picar código.

Veamos algunos aspectos relevantes:

- Aprendizaje - servicio: los retos deben resolver alguna situación que tenga sentido y utilidad. No tiene porqué ser algo social, puede resolver cuestiones de ocio (por ejemplo una parte en concreto de un videojuego que hay que programar), pero es importante que se plantee una situación que entraña un problema a solucionar.

- La forma de presentar el reto debe ser variada. De esta forma se acostumbrarán a tener que entrenar su capacidad de identificar un problema que puede ser resuelto programando. Podemos plantear retos escritos, retos en vídeo, un audio, un problema que se percibe en una imagen, una mera idea expresada en modo esquema, un diagrama de flujo… Una buena idea es indicar cada persona o grupo serán una empresa que tiene que dar respuesta a peticiones comerciales, de esta forma la manera de presentar los retos puede ser diversa y el cliente sólo quedará satisfecho y si se le entrega lo que está pidiendo. Esta idea se puede extender a la creación de un nombre y logo y realizar un blog dando las respuestas…

- El enfoque debe ser neutro o compensado. La programación actualmente tiene un marcado toque masculino y es importante buscar retos compensados, que fomenten todos los intereses y no sólo se centren en mundos tradicionalmente vinculados a los hombres (por ejemplo siempre hablar de videojuegos, deportes y robots de combate hace que el sector femenino pierda interés). Podemos plantear retos neutros y/o retos más femeninos y más masculinos de forma compensada.

- Lo que se pide en el reto debe ser, así mismo, diverso. No siempre habrá que programar sin más, en ocasiones se puede pedir que expliquen una programación, que la comenten, que la corrijan, que la modifiquen para usarla en otro ámbito o problema, que la esquematicen, que hagan un diagrama de flujo, que terminen una programación ya iniciada, que adivinen que quería hacer alguien que empezó un programa...

- Cuidado con los tiempos. Las clases tienen una duración reducida, los retos no deben ser inabarcables, pues entonces estaríamos hablando de proyectos y todo lo anterior no tendría sentido. Trabajando de forma individual o por grupos pequeños los retos no deberían ocupar más de una o dos clases.

- De cara a la evaluación: no trates de evaluar subjetivamente los retos, lo más sencillo es elaborar una serie pequeña de aspectos de la resolución del reto que se puedan evaluar con un simple correcto/incorrecto y con una nota asociada a cada uno de esos aspectos. Digamos que sería una rúbrica pero sin grados de consecución, simplemente o está o no está bien hecho. Los aspectos a evaluar pueden ser:

1- ¿Está resuelto?

2- ¿Entrega la solución en la forma que se pide?

3- La solución es idónea

Un reto puede estar resuelto pero no en la forma idónea y también puede estar resuelto pero no presentar lo que estamos pidiendo (por ejemplo un diagrama de flujo, o un programa sin comentarios cuando los pedíamos). No tiene sentido enfrascarse en corregir y corregir, si los alumnos resuelven unos 10 retos y de cada uno evaluamos dos o tres aspectos estamos tomando bastantes notas y el resultado será bastante fiel a cómo ha sido el proceso de aprendizaje.

Por último, hay que tener cuidado de que no copien las soluciones de otros grupos, este aspecto es complejo, pero quizá aleatoriamente se pueda preguntar a miembros de algún grupo sobre la resolución de un reto que han presentado y si no saben explicarlo directamente no les cuenta o algo así. Aun así, mi experiencia me ha demostrado que si están motivados no quieren la solución de otros compañeros, quieren la suya.

A esto podemos sumar alguna pequeña prueba donde preguntemos aspectos básicos o nos contesten a algunas cuestiones (un típico examen o test) o la exposición de alguno de los retos frente al grupo…

Para la nota total podemos decidir que se empezará a evaluar a partir de una cantidad de retos resueltos, los cuales tendrán una nota media y el resto de retos extra que se hagan serán ponderadores de la media, sumarán alguna cantidad o algo así. No es buena idea favorecer un ritmo de aprendizaje diferenciado y evaluar con menos nota a los que trabajen a un ritmo más lento por sus capacidades. Hay que premiar el esfuerzo, no sólo el resultado. Con ello no quiero decir que tenga que tener un 10 el que no hace casi nada, simplemente habrá que poner una cantidad de retos óptima como nota y el que trabaje más allá de eso podrá ir sumando más nota. También podemos poner un baremador por tiempo, si entregas más tarde de una fecha va bajando la nota que tendrá tu reto…

Como ves, elaborar tu propuesta de aula es complejo y seguramente las primeras veces salga más bien regular. Es lo normal, todo proceso nuevo conlleva un aprendizaje y hay que ir haciendo el medio idóneo para la personalidad del docente, no todos podemos trabajar de la misma forma ni tampoco es ello positivo para el alumno, la diversidad le enseña mucho mejor cómo es el mundo en el que va a trabajar en el futuro.

Medio de trabajo

Me decanto claramente por Google Drive. Los alumnos pueden crear cuentas (siempre informando a las familias, que tendrán que crearlas si los alumnos son menores) y se puede compartir desde el docente una carpeta a cada grupo y ahí pueden ir colgando sus retos. El entorno Drive permite crear documentos, presentaciones, hojas de cálculo, subir archivos .py, fotos, vídeos… De esta forma se puede trabajar muy bien con ellos. Además, queda registro de los cambios y eso es bueno por si deciden hacer cambios fuera de plazo o incluso fastidiarse entre ellos.

Hay una herramienta muy buena para “editar” código en un documento de texto de google, se llama Code Pretty y te permite editar código si está incluido en tablas dentro del documento.

Si hay algo que va a determinar cómo va a ser el proceso va a ser el principio, las primeras clases. Es importante plantear unas primeras sesiones motivadoras, que vinculen al alumno con lo que va a aprender, si no el proceso será mucho más complicado. Una gran parte del éxito del proceso viene determinado por la primera impresión que tenga el alumno de lo que va a suceder en el aula en sus clases de programación. Por ello sería muy bueno que al principio los alumnos viesen el potencial de la programación, sintiesen ganas por empezar. Obviamente todos sabemos que es complicado que una acción motivadora surta efecto en todos los alumnos, pero cuanto más esfuerzo hagamos en motivar más fácil será el camino posterior.

Intenta crear un medio en donde los alumnos aprendan cómo resolver sus propias dudas, acudiendo a información o incluso a otros alumnos que ya han logrado resolver esa duda.

Deja que aprendan a su ritmo, intentar que todos avancen al mismo tiempo y de la misma forma es garantía de fracaso.

No te atormentes con la evaluación tradicional, busca pequeños indicadores de consecución de objetivos y haz que la suma de muchos de ellos determinen la nota.

Alfredo Sánchez Sánchez

Graduado en Ingeniería de Edificación por la Universidad Politécnica de Madrid, máster del Profesorado en la Universidad Camilo José Cela. Ha trabajado en el departamento educativo de BQ. Actualmente es profesor de matemáticas y tecnología en ESO. Entusiasta de la pedagogía y el mundo maker, intenta motivar el cambio en el sistema educativo.

Actualmente imparte un curso de programación para profesores de secundaria o bachillerato en el Campus Tecnológico Virtual: Curso Python