RAILS D'ENSEIGNEMENT

Les calculs

Au cours des quatre mois suivants, nous nous sommes rencontrés toutes les deux semaines et pas à pas, nous avons découvert The Awesome World of Ruby et al. Le cours couvrait le langage Ruby, Ruby on Rails, Javascript et quelques outils populaires pour les applications de RdR comme Devise, Pundit, Sidekiq ou Carriewave.

Chaque étudiant avait également un mentor, chargé de le motiver et de vérifier son travail entre les réunions.

Le plan d'attaque

En tant qu'enseignant, je me suis préparé avec 3 ans d'expérience avec Ruby on Rails, 10 ans d'expérience avec la programmation en général et quelques présentations avec des questions et des exercices à faire.

À l'exception d'un court cours de gestion Linux que j'avais suivi auparavant, je n'avais aucune expérience de l'enseignement. Quant aux étudiants, je savais seulement qu'ils allaient être dix et qu'ils venaient d'horizons très différents - pour certains d'entre eux, il s'agissait de leur premier contact avec la programmation, tandis que d'autres avaient essayé d'apprendre le C ou le Ruby par eux-mêmes avant de s'inscrire au cours.

J'ai décidé de prendre deux résolutions - je serai patient et j'expliquerai tout si nécessaire (pas de "nous avons déjà abordé le sujet"). La première résolution a résisté à l'épreuve du temps, mais la seconde - de toute évidence - ne l'a pas fait. J'ai décidé de ne pas faire de préparation spéciale concernant les choses que j'allais enseigner - je travaille avec Ruby/Rails tous les jours et je suis assez confiant dans mes compétences dans ce domaine. Tout au plus, j'ai lu les présentations que j'avais.

Le défi

L'une des premières choses qui m'est apparue clairement dès le début du cours, c'est qu'on ne peut pas tout expliquer. C'est une prise de conscience très triste pour quelqu'un comme moi, qui aime creuser et découvrir comment les choses fonctionnent, mais dans le temps limité d'une réunion, il y a des limites à ce que l'on peut enseigner et qui peut être retenu par les étudiants. Il s'avère que l'on peut être un programmeur Ruby très décent sans savoir exactement comment les tableaux sont représentés en mémoire ou comment Devise fonctionne.

Les cours avaient lieu le samedi et le dimanche de 9 heures à 17 heures. Il est important de comprendre que l'enseignement est un travail assez épuisant - en plus d'expliquer la matière, vous devez toujours être prêt à répondre à des questions connexes (ou non) et à résoudre les différents problèmes que rencontrent vos élèves.

Le café est votre ami, mais le plus important est la patience. Pour les personnes qui n'ont jamais codé, les concepts qui sont évidents pour les programmeurs - comme les boucles, les types ou même les variables - doivent être appris et ce n'est pas un processus instantané. Si vous programmez depuis XX ans, que vous considérez les mathématiques comme faciles et que vous pouvez énumérer tous les paradigmes de programmation connus au milieu de la nuit, il peut être difficile de se mettre à la place d'une personne qui ne sait pas vraiment de quel côté du signe égal se trouve le nom de la variable. Mais il est essentiel que vous le fassiez. Des concepts de base comme les variables, les boucles ou les tableaux deviennent si naturels qu'il est difficile de comprendre comment quelqu'un peut ne pas les comprendre tout de suite, mais ils sont plus difficiles qu'ils ne le paraissent pour "nous, les programmeurs".

Une difficulté supplémentaire, surtout au début du cours, a été d'expliquer ces concepts pour qu'ils soient bien compris. À mon avis, il n'est pas possible d'apprendre Rails sans apprendre Ruby - même si je sais que certains diront le contraire. Il est vrai que Rails a ses propres modèles et que beaucoup de choses peuvent être mémorisées plutôt qu'apprises au début. Cependant, je pense que pour devenir un développeur Rails conscient, une compréhension modérée de Ruby, de la POO ou de SQL est indispensable. Apprendre à programmer est très différent d'enseigner Rails - alors qu'avec Rails, on peut s'attendre à ce que beaucoup de choses soient simplement acceptées ou crues (personne n'a besoin de savoir comment les callbacks fonctionnent au début - seulement ce qu'ils peuvent faire), les concepts de programmation doivent être expliqués plus en détail.

Engager la force

Alors, comment faire ?

Patiemment.

J'ai probablement l'impression de me répéter sans cesse, mais je ne saurais trop insister sur l'importance de la patience. Même mes étudiants les plus motivés sont connus pour faire une erreur de syntaxe ici et là - cela fait partie du processus normal d'apprentissage et il n'y a pas vraiment d'autre chose à faire pour un enseignant que de montrer ce qu'est l'erreur et comment la corriger. Avec le temps, ils apprendront à les corriger eux-mêmes, mais il faudra pour cela bien plus qu'une ou deux erreurs.

Une autre chose à noter est que Ruby n'est pas aussi facile qu'il n'y paraît. Si vous avez commencé à apprendre Ruby avec des connaissances en C/Java/Python, tout vous a probablement semblé si propre, si beau et si simple. Essayez d'y réfléchir et vous vous en rendrez compte :

1. Pourquoi des parenthèses ? Dois-je les utiliser ? Ne dois-je pas les utiliser ?
2. Qu'est-ce que c'est ? soi chose ? Parfois, je dois l'utiliser (ex. attr_writer – self.variable = ...), parfois je ne le fais pas (attr_reader – variable) et parfois je ne peux pas ! (private def some_method – self.some_method génère une erreur)
3. Les blocs. Je parie que même des programmeurs expérimentés (de différents langages) auraient besoin d'un peu plus de temps que prévu pour comprendre #inject

Outre la simple correction des erreurs, il y a la question de la transmission de votre compréhension des choses à vos élèves. Pour ce faire, vous aurez besoin d'une grande flexibilité. Certains élèves se sont contentés d'une simple liste ordonnée d'éléments pour Array. D'autres avaient besoin d'une analogie plus visuelle, comme une étagère avec des emplacements numérotés sur lesquels on peut poser des objets. Je me suis retrouvée à expliquer plusieurs fois les mêmes choses de différentes manières, ce qui est un exercice très stimulant !

Mais, comme je l'ai déjà dit, on ne peut pas tout expliquer. Quand j'expliquais les relations dans Rails, c'était plus un "c'est comme ça qu'on fait, et ça permet de faire ça et ça. Vous voulez ça, c'est génial". Heureusement, personne ne m'a demandé comment cela fonctionnait - je ne pense pas que les développeurs juniors aient besoin de connaître les réflexions.

Positionnement situationnel

En raison du format de notre cours (réunions un week-end sur deux et longues pauses), nous avons dû veiller à ce que les périodes entre ces week-ends soient productives pour nos étudiants - sans eux, le cours ne fonctionnerait pas du tout.

Certains de mes collègues ont accepté d'être les mentors des étudiants du cours. Le travail des mentors consistait à vérifier les exercices assignés lors des réunions du week-end et à aider à résoudre les problèmes qui se posaient pendant la réalisation des exercices. Les étudiants communiquaient avec les mentors via Slack.

J'ai été le mentor de deux de mes étudiants. C'était une forme d'enseignement très différente - et pleine de pièges. J'ai compris un peu trop tard qu'un bon programmeur doit être indépendant - il doit au moins essayer de résoudre les problèmes par lui-même avant de demander de l'aide. Et le fait d'être disponible en permanence sur Slack non seulement me prenait beaucoup de temps, mais n'inspirait pas non plus une telle indépendance.

Ne vous méprenez pas, beaucoup de questions qui m'ont été posées en tant que mentor étaient valables et y répondre permettait d'approfondir les connaissances des étudiants. Il est cependant très facile de passer en mode "enseignant" et de réexpliquer tous les problèmes soulevés lors des réunions du week-end. Du point de vue actuel, je pense que le rôle d'un mentor est de donner une vue d'ensemble, de fournir des liens utiles et de poser des questions qui peuvent aider à trouver la solution. Il peut arriver que des explications soient données, mais cela ne devrait pas être la majorité.

L'utilisation du renseignement

Chaque étudiant est différent. L'une des plus grandes difficultés a été d'ajuster le rythme du cours pour qu'il convienne le mieux possible à tous les étudiants. En raison de la diversité des origines et du niveau général de facilité à accepter de nouvelles idées entre les étudiants, c'est une tâche presque impossible.

Notre délai était de 9 réunions - multiplié par 2 jours et 8 heures, ce qui nous donnait 144 heures pour passer de 0 à Ruby-hero. Il était primordial de suivre l'intégralité du programme dans ce laps de temps - ce qui, en soi, imposait un rythme assez rapide. Les trois premières réunions étaient consacrées à Ruby - puis une réunion pour SQL, puis RoR et une réunion pour JS entre les deux.

En tant qu'enseignant, j'ai toujours eu besoin de savoir qui comprenait plus ou moins bien une partie du matériel que je présentais. Parfois, il suffisait de demander si cela avait été compris, parfois je faisais de petits tests. Par exemple, j'ai demandé à tous mes étudiants de m'envoyer leurs propres définitions des concepts de Ruby, comme par exemple classe, soi, méthode, variable etc. sur Slack. Si une question n'était pas claire, je revenais en arrière et essayais de la réexpliquer.

Illusion et réalité

En résumé, l'enseignement a été une entreprise encore plus difficile que je ne l'imaginais. Il peut également être très gratifiant. Néanmoins, il s'agit d'un travail difficile dont les effets ne dépendent pas uniquement de l'enseignant - les efforts de l'étudiant sont encore plus importants dans leur apprentissage. L'enseignement est donc très différent de la programmation, où l'on peut généralement s'approprier tous les succès et tous les échecs. Il est important de se souvenir de cette différence.

Cela vous oblige également à réfléchir à des questions auxquelles vous ne pensez pas habituellement - expliquer les choses vous permet également de mieux les comprendre. De cette manière, l'enseignement peut également faire de vous un meilleur programmeur.