Este es la primera entrada que escribo para la categoría “Para maestr@s”. He estado retrasando la escritura de estos posts, sin motivo consciente aparente, pues en realidad es la ayuda hacia l@s docentes de programación la que generó la idea de dCodinGames.

Me gradué como ingeniera en computación hace ya varios ayeres, y aunque he hecho algunos trabajitos por aquí y por allá como freelancer, mi trabajo principal y fuente de ingresos personales ha sido en la enseñanza.  He sido bendecida, creo yo, porque a lo largo del tiempo me he dado cuenta que trabajo en dos de mis pasiones: la programación de computadoras y la enseñanza. Por ese motivo creo que tengo algo de experiencia que quiero compartir con ustedes, en forma de lecciones que he aprendido mientras enseñaba.

Lección # 1: El maestro no se debe al temario, sino al estudiante.

A lo largo de mi carrera como docente he sido testigo de los cambios en el uso de las Tecnologías de la Información. Por ejemplo, recuerdo que, incluso al inicio del siglo XXI, me topaba con estudiantes que era la primera vez que conocían una computadora, ¿y yo pretendía hablarles de ciclos, contadores, acumuladores y funciones recursivas? ¡Por supuesto que tuve que ir más atrás, enseñando incluso como usar un mouse! Y ahí aprendí mi lección más importante: El maestro no se debe al temario, sino al estudiante.

¿Qué quiero decir con esto? Otra de mis grandes pasiones es el futbol americano. Para quienes conocen el tema sabrán que uno de los equipos más ganadores de los últimos años son los New England Patriots (dejemos de lado la controversia, porque si no nunca llegaremos al punto importante) Después de haber ganado en el 2001, era muy lógico que comenzaran lo que sucede con todos los equipos: una lenta pero inevitable caída. Estamos en el 2018 y los expertos los siguen colocando como posibles ganadores del Super Bowl. Eso quiere decir que este equipo ha sido contendiente al campeonato 17 años consecutivos:  17 años en los que han tenido bajas de juego de jugadores, retiros de estrellas clave, y por supuesto en los que han incorporado a jóvenes e inexpertos talentos, pero nunca han perdido su estatus de favoritos. ¿Cómo lo han hecho? El secreto radica en que el coach Bill Belichick ha sabido adaptar su sistema de juego a los jugadores que tiene en el momento: cuando tuvieron a un corredor, la ofensiva fue terrestre, cuando tuvieron a un gran receptor, la ofensiva fue aérea.

Y yo me pregunto: ¿no debemos como docentes hacer lo mismo? Entiendo que ciertos puntos del temario deben ser obligatorios y estandarizados, pero el ritmo de trabajo lo definen los estudiantes. Si tengo alumnos a los que les cuesta entender un concepto, ¿debo ignorar el hecho porque ha sido explicado en clase n veces, y continuar con el temario, porque el tiempo es oro? ¿No sería mejor crear una estrategia para que mis alumnos entiendan ese concepto, aunque eso implique repetir una clase nuevamente?

Incluso sucede con grupos brillantes, en donde ya han entendido cierto concepto y su misma curva de aprendizaje te exige más. ¿Podemos simplemente ignorarlos y guiarnos por el temario, aun cuando los estudiantes ya nos han demostrado que eso ya lo conocen?

Pienso que, en lugar de estandarizar, deberíamos optar por adaptar el temario a las características de los estudiantes del grupo.

Lección # 2. De los errores también se aprende.

Incluso se aprende mucho más cuando las cosas salen mal que cuando todo funciona correctamente. Por lo menos, en programación es una regla no escrita.

Nos esforzamos tanto porque nuestros estudiantes no cometan errores, porque se aprendan de memoria la sintaxis del lenguaje de programación y esperamos que mágicamente cuando es su turno de escribir un programa por sí solos éste funcione correctamente a la primera. ¿Esto es real?

Si bien es claramente necesario que los estudiantes aprendan la sintaxis de los elementos del lenguaje, ese conocimiento por sí solo no los convierte en programadores. Es solo a través del entrenamiento constante de la mente, a través de solucionar diversos problemas, de aprender como ciertas soluciones pueden aplicarse a problemas diferentes, a través de saber leer tu propio código, pero también el del compañero, y, sobre todo, a través de poder solucionar los errores y entender el origen de estos errores… así es el camino de convertirse en programador.

La experiencia de mi propio aprendizaje de la programación me enseñó lo mucho que crecí encontrando errores en mi código, depurándolos y entendiendo porqué en una línea de código el compilador había marcado un error. Por lo tanto, sí puedo decir que aprendí más depurando errores, que memorizando la sintaxis del lenguaje.

Si sabes depurar un programa, conoces la sintaxis del lenguaje, entiendes el problema y la lógica del programa. Para mí eso implica que deberíamos enseñar apoyándonos más en la depuración y rastreo de un programa que en la simple transferencia de conocimientos.

El estudiante debe entender que es deseable cometer los menores errores posibles, pero que, si hay errores, no es el fin del mundo. Y lo más importante, que, si confía en su entrenamiento, llegará un momento en que será capaz de encontrar y corregir por sí solo sus propios errores, y no será por casualidad ni por suerte, sino resultado de su proceso mental de aprendizaje.

Lección # 3. Baby steps.

Al no tener una formación docente como tal, desconozco mucho sobre teorías del aprendizaje y los modelos taxonómicos cognitivos, estoy comenzando a investigar y aprender sobre estos temas. Pero es claro que la finalidad de enseñar programación es que los estudiantes sean capaces de escribir sus propios programas y eso entra dentro de la categoría cognitiva “Crear” de acuerdo a la taxonomía de Bloom.

Pero para poder llegar a crear, el alumno tiene que pasar por Recordar, Comprender, Aplicar, Analizar y Evaluar. Por lo tanto, debemos ser nosotr@s, sus maestr@s los que guiemos ese proceso, desmenuzándoles el conocimiento, dosificándolo, creando actividades que los lleven por estas categorías antes de crear. Es decir, guiarlos poco a poco, aunque den pasitos de bebé.

Desconozco como enseñan l@s colegas modernos, pero tengo muy fresca mi experiencia como aprendiz de programación y las únicas actividades de mi maestro eran siempre las mismas: “Escriba un programa para…” ¿En serio? Yo no tenía idea de cómo debía hacerlo, y aun cuando había memorizado todas las reglas sintácticas del lenguaje, no estaba claro el cómo debía comenzar siquiera a escribir el algoritmo, ¿y debía escribir el programa?

Es por eso que yo me voy hasta lo más básico, incluso aquello que pudiera parecer que el estudiante ya lo sabe: qué es una variable, qué es una constante, como se usan, cuáles son los operadores del lenguaje, etc. Parecería que el alumno ya trae el conocimiento por su cercanía de estos conceptos con las matemáticas, pero en realidad la forma en que se usan en programación es muy diferente y causa confusión en más de uno. Avance con pasitos de bebé (“Baby steps”), poco a poquito, que el camino es largo y el destino está lejos.

Lección # 4. La práctica hace al maestro.

Esta máxima es cierta en más de un nivel. Mientras más oportunidades de programar tiene un estudiante, más se entrena su cerebro para esta actividad, desarrollando las conexiones conocimientos-experiencias en su cerebro. Observemos como es el modelo de entrenamiento de un aprendiz de cirujano: primero se le permite observar una cirugía, posteriormente se le va dando la oportunidad de participar en pequeños procedimientos, y así sucesivamente hasta que llega el día en que puede realizar su primera intervención quirúrgica por sí solo.  Este es un proceso de entrenamiento con retos acordes a su nivel de conocimientos-experiencias que le permite desarrollarse y crecer.

De la misma forma sucede con los estudiantes, pero también con l@s maestr@s. Hace mucho tiempo, escuché como un colega enseñaba a sus estudiantes y quedé perpleja:

“Yo sólo les escribo el programa en el pizarrón, y ya, ellos que lo transcriban en el IDE y lo prueben. Si tienen errores, es porque no capturaron bien. Y eso es todo. No veo porqué esforzarme más, si de todos modos no van a aprender”. 

L@s docentes que piensan de ese modo también se niegan a practicar: a practicar el cómo enseñar. A menudo nos quejamos porque los estudiantes se quejan de las incontables tareas y programas que les asignamos, pero lo justificamos diciendo que mientras más practiquen, más van a aprender. Y es cierto, pero también lo es hacia el otro sentido: es a través de la constante práctica del arte de enseñar cómo te vas haciendo expert@. Y más en la enseñanza de la programación, ya que los que nos dedicamos a esto, tenemos formación de corte ingenieril, no pedagógica. Entonces es más que normal que los primeros cursos cometamos muchos errores, pero si realmente te abres a la posibilidad de que en realidad puedes ayudar a alguien a aprender a programar, buscarás investigar técnicas, probar lo que funciona y lo que no, en una palabra: practicar.