RAÍLES DIDÁCTICOS

Los cálculos

Durante los cuatro meses siguientes nos reunimos cada dos semanas y, paso a paso, fuimos descubriendo The Awesome World of Ruby et al. El curso cubría el lenguaje Ruby, Ruby on Rails, Javascript y algunas herramientas populares para aplicaciones RoR como Devise, Pundit, Sidekiq o Carriewave.

Cada estudiante tenía también un tutor, que se encargaba de motivar a los alumnos y revisar su trabajo entre reunión y reunión.

El plan de ataque

Como profesor, vine preparado con 3 años de experiencia con Ruby on Rails, 10 años de experiencia con programación en general y algunas presentaciones con temas y ejercicios para hacer.

Aparte de un breve curso de gestión de Linux que había hecho antes, no tenía ninguna experiencia con la enseñanza. En cuanto a los alumnos, sólo sabía que iban a ser diez y que procedían de entornos muy distintos: para algunos es su primer contacto con la programación, mientras que otros intentaron aprender C o Ruby por su cuenta antes de matricularse en el curso.

Decidí hacer dos propósitos: ser paciente y explicarlo todo si era necesario (nada de "ya lo hemos hablado"). El primer propósito ha resistido el paso del tiempo, pero el segundo, obviamente, no. Decidí no hacer ninguna preparación especial con respecto a las cosas que iba a enseñar - trabajo con Ruby/Rails todos los días y me siento bastante seguro de mis habilidades en esa área. Como mucho, leí las presentaciones que tenía.

El desafío

Una de las primeras cosas que me quedó absolutamente clara nada más empezar el curso fue que no se puede explicar todo. Es una triste realidad para alguien como yo, a quien le gusta profundizar y descubrir cómo funcionan las cosas, pero en el tiempo limitado de una reunión no se puede enseñar tanto y que pueda ser recordado por los estudiantes. Resulta que puedes ser un programador Ruby muy decente sin saber exactamente cómo se representan realmente los Arrays en memoria o cómo funciona exactamente Devise.

Las clases se impartían los sábados y domingos de 9 de la mañana a 5 de la tarde. Hay que tener en cuenta que la enseñanza es un trabajo agotador: además de explicar la materia, hay que estar siempre dispuesto a responder a preguntas relacionadas (o no tan relacionadas) y a resolver los distintos problemas de los alumnos.

El café es tu amigo, pero lo más crucial es la ya mencionada paciencia. Para las personas que no han codificado antes, conceptos que son obvios para los programadores -como bucles, tipos o incluso variables- necesitan ser aprendidos y no es un proceso instantáneo. Si llevas XX años programando, consideras que las matemáticas son fáciles y puedes enumerar todos los paradigmas de programación conocidos en mitad de una noche, puede que te resulte difícil ponerte en la piel de una persona que no sabe muy bien a qué lado del signo igual va el nombre de la variable. Pero es vital que lo hagas. Conceptos básicos como variables, bucles o arrays se vuelven tan naturales que es difícil comprender cómo puede alguien no entenderlos enseguida, pero son más difíciles de lo que parecen para "nosotros los programadores".

Una dificultad añadida, sobre todo al principio del curso, era explicar esos conceptos para que se entendieran bien. En mi opinión, no es posible aprender Rails sin aprender Ruby, aunque sé que algunos dirán que no es así. Es cierto que Rails tiene sus propios patrones y muchas cosas se pueden recordar más que aprender al principio. Sin embargo, creo que para convertirse en un desarrollador RoR concienzudo es imprescindible tener unos conocimientos moderados de Ruby, programación orientada a objetos o SQL. Enseñar a la gente a programar es bastante diferente que enseñar Rails - mientras que con Rails hay muchas cosas que puedes esperar que simplemente se acepten o se crean (nadie necesita saber cómo funcionan los callbacks al principio - sólo lo que pueden hacer), los conceptos de programación deben explicarse con más detalle.

Involucrar a la Fuerza

¿Cómo se hace eso?

Pacientemente.

Probablemente parezca que me repito todo el rato, pero no puedo dejar de recalcar lo importante que es la paciencia. Incluso mis alumnos más motivados cometen errores de sintaxis de vez en cuando: forma parte del proceso normal de aprendizaje y el profesor no puede hacer otra cosa que mostrarles en qué consiste el error y cómo corregirlo. Con el tiempo, aprenderán a corregirlos por sí mismos, pero para ello necesitarán mucho más que uno o dos errores.

Otra cosa a tener en cuenta es que Ruby no es tan fácil como parece. Si empezaste a aprender Ruby con conocimientos de C/Java/Python, probablemente todo parecía tan limpio y agradable y simple. Sin embargo, intenta pensar en ello y te darás cuenta:

1. ¿Qué pasa con los paréntesis? ¿Debería usarlos? ¿No debería?
2. ¿Qué es eso? auto ¿cosa? A veces tengo que usarlo (eg. attr_writer – self.variable = ...), a veces no (attr_reader – variable) ¡y a veces no puedo! (private def algún_método – self.algún_método arrojará un error)
3. Bloques. Apuesto a que incluso algunos programadores experimentados (de diferentes lenguajes) necesitarían un momento más de lo esperado para entender #inject

Aparte de la simple corrección de errores, está la cuestión de transmitir a los alumnos lo que tú entiendes. Para ello, necesitarás mucha flexibilidad. A algunos alumnos les bastaba con que Array fuera una lista ordenada de elementos. Otros necesitaban una analogía más visual, como una estantería con lugares numerados en los que colocar cosas. Tuve que explicar las mismas cosas varias veces de distintas maneras, ¡lo cual es todo un reto!

Pero, como he dicho antes, no se puede explicar todo. Cuando explicaba las relaciones en Rails, era más un "así es como se hace, y te permite hacer eso y aquello. Si quieres eso, es genial". Afortunadamente nadie me preguntó cómo funcionaba - no creo que los desarrolladores junior necesiten saber sobre reflexiones.

Posicionamiento situacional

Debido al formato de nuestro curso (reuniones en fines de semana alternos y largas pausas), tuvimos que asegurarnos de que los periodos entre esos fines de semana fueran productivos para nuestros estudiantes: sin ellos practicando en ese tiempo, el curso no funcionaría en absoluto.

Algunos de mis compañeros de trabajo aceptaron ser mentores de los alumnos del curso. El trabajo de los mentores consistía en verificar los ejercicios que se asignaban durante las reuniones de fin de semana y ayudar con los problemas que surgían al completarlos. Los estudiantes se comunicaban con los mentores a través de Slack.

Fui mentor de dos de mis alumnos. Era una forma de enseñar muy diferente, y llena de sus propias trampas. Una cosa de la que me di cuenta un poco tarde es que un buen programador debe ser independiente: al menos debe intentar resolver los problemas por sí mismo antes de pedir ayuda. Y estar disponible en Slack todo el tiempo no solo me quitaba mucho tiempo, sino que además no inspiraba esa independencia.

No me malinterpreten: muchas de las preguntas que me hacían como mentor eran válidas y responderlas era ampliar los conocimientos de los alumnos. Sin embargo, es muy fácil ponerse en "modo profesor" y volver a explicar todas las cuestiones de las reuniones del fin de semana. Desde la perspectiva actual, creo que el papel de un tutor es ofrecer una visión general, proporcionar enlaces útiles y hacer algunas preguntas que puedan ayudar a encontrar la solución. De vez en cuando hay que dar explicaciones, pero no deberían ser la mayor parte del tiempo.

El uso de la inteligencia

Cada estudiante es diferente. Una de las mayores dificultades fue ajustar el ritmo del curso para que se adaptara lo mejor posible a todos los estudiantes. Debido a la diversidad de procedencias y al nivel general de facilidad para aceptar nuevas ideas entre los estudiantes, es una tarea casi imposible.

Teníamos 9 reuniones, 2 días y 8 horas, lo que nos daba 144 horas para pasar de 0 a Ruby-hero. Era primordial hacer todo el programa de estudios en este tiempo, lo que de por sí imponía un ritmo bastante rápido. Las tres primeras reuniones fueron sobre Ruby, luego una sobre SQL, otra sobre RoR y una tercera sobre JS.

Como profesor, siempre tenía que saber quién entendía más o menos parte del material que presentaba. A veces bastaba con preguntar si se entendía, otras veces hacía pequeñas pruebas. Por ejemplo, pedía a todos mis alumnos que me enviaran sus propias definiciones de conceptos de Ruby, como clase, auto, método, variable etc., en Slack. Si alguna cuestión no quedaba clara, volvía e intentaba explicarla de nuevo.

Ilusión y realidad

En resumen, enseñar ha sido una tarea aún más difícil de lo que pensaba. También puede ser muy gratificante. No obstante, es un trabajo duro y sus efectos no dependen únicamente del profesor: el propio esfuerzo del alumno es aún más importante en su aprendizaje. Esto hace que la enseñanza sea muy diferente de la programación, en la que uno suele ser dueño de todos los éxitos y fracasos. Es importante recordar esta diferencia.

También te obliga a reflexionar sobre temas en los que no sueles pensar: explicar las cosas también te permite comprenderlas mejor. De este modo, enseñar también puede convertirte en mejor programador.