Astuces pour mentorer un groupe d’étude de programmation
Les ateliers débutants Rails Girls sont supers pour susciter beaucoup d’enthousiasme, motiver les nouveaux à aller plus loin et commencer à apprendre à programmer.
De temps en temps, les participants de ces ateliers forment des groupes d’étude en Ruby. Voici quelques recommandations sur comment faire marcher un tel groupe en tant que mentor, basé sur notre propre expérience Ruby Monsters.
Bonheur et plaisir
Quelles que soient les précédentes expériences et compétences que possède votre groupe, votre travail en tant que mentor est de faire en sorte que l’apprentissage de la programmation soit intéressant. Les réunions du groupe doivent être aussi amusantes que possible. Vous voulez que vos étudiants soient heureux quand ils quittent l’espace de travail : un peu fatigués, peut-être légèrement perdus, mais toujours heureux.
Cela peut être difficile, vous pouvez vous retrouver bloqué. Continuez d’apprendre vous-même. Essayez de trouver de nouvelles manières d’expliquer et améliorez vos acquis.
Créez un environnement sûr
À notre groupe de travail, nous avons trouvé que le plus simple était de n’accepter que des femmes en tant qu’étudiant. (“Femme” signifiant toute personne qui s’identifie en tant que femme).
Bien que nous ne soyons pas nécessairement opposés à accepter des hommes en tant qu’étudiants, nous voulons que ces groupes soient un endroit génial pour les femmes qui veulent apprendre la programmation, à leur propre rythme et à leur propre manière.
De plus, dès qu’il y a ne serait-ce qu’un étudiant masculin, la dynamique change radicalement. Nous nous sommes trouvés nous-même quelquefois en difficulté pour lutter contre cette dynamique et faire en sorte que chacun vive la meilleure expérience possible.
Nous avons donc décidé de simplement fermer notre groupe aux étudiants masculins. Ils sont invités à visiter le groupe, suivre un atelier, attendre leur compagne, mais sont aussi invités à trouver une place à l’écart et à garder le silence afin de ne pas perturber le groupe.
Nous vous recommandons de garder la même politique pour votre groupe, ou au minimum d’avoir une politique claire sur qui est autorisé à rejoindre votre groupe.
Ne jamais appeler les participantes ‘les filles’
Malgré le nom et l’image de marque du mouvement RailsGirls, en tant que mentors, nous n’appelons jamais nos participantes ‘les filles’.
Elles peuvent utiliser ce terme entre elles autant qu’elles veulent, c’est leur choix. En tant que mentors, nous les appelons participantes, étudiantes, membres (de notre groupe), développeuses ou femmes en fonction du contexte.
Cela doit être un reflexe pour vous. Si ça ne l’est pas, ou si vous avez un souci avec cette règle simple, nous vous recommandons de prendre du recul et d’étudier d’avantage les problèmes liés au genre dans notre société en général et dans le milieu Tech plus particulièrement.
Quelques grands points de départ sont consultables ici, ici, et ici, et vous pouvez trouver plus de ressources à la fin de cette page.
Si étudier ces sources ne vous convainc toujours pas, vous pourriez alors ne pas être la bonne personne pour faire marcher un groupe d’étude réservé aux femmes.
Soyez humble: vous n’êtes pas le centre d’attention
Quoi que vous fassiez, restez concentré sur vos élèves. Elles sont le groupe d’étude, pas vous.
Votre travail est de les aider à apprendre tout en s’amusant, de rester motivé, enthousiaste et content de leurs progrès.
Soyez humble: vous n’êtes pas le centre d’attention.
Prenez des pauses
Pendant les ateliers, il est important de prendre des pauses.
Vos étudiantes seront plus rapidement fatiguées que vous puisqu’elles découvrent de nouvelles choses. Quoi qu’il en soit, la plupart du temps, être mentor est aussi très fatiguant.
Faites en sorte de garder un oeil sur le temps que vous mettez à expliquer un nouveau concept ou à les laisser résoudre un problème par elles-même. Prenez des pauses fréquemment.
Pendant les pauses, encouragez tout le monde à fermer les pc, aller faire un tour, discuter et prendre une collation.
Posez des questions sur les expériences précédentes
Souvent, les étudiantes qui prennent part à nos groupes de débutantes n’ont aucune expérience en programmation. De temps en temps, elles ont quelques notions de HTML/CSS, ont déjà fait des modifications sur un blog WordPress ou ont hacké un mode dans un jeu vidéo. D’autres sont ou ont été étudiantes en science de l’informatique, mais trouvent les cours de Java ou d’Haskell qu’elles ont suivi tellement nuls qu’elles recherchent une meilleure alternative.
Pendant votre tout premier atelier, et à chaque fois qu’une nouvelle personne rejoint le groupe, demandez les expériences et compétences déjà acquises, ainsi que la motivation qui les pousse à rejoindre le groupe. Cela vous donnera quelques clés pour savoir comment commencer et les compétences sur lesquelles vous appuyer.
Restez aussi simple que possible
Si vous pensez pouvoir mentorer un groupe de débutantes, vous êtes probablement un développeur expérimenté.
Gardez à l’esprit qu’être un bon développeur et être un bon professeur et/ou mentor sont deux choses bien distinctes qui requièrent différentes compétences.
Quels que soient vos propres centres d’intérêt, vos outils préférés, le style de programmation que vous aimez, vous avez mis des années avant de créer vos propres habitudes et vos propres réflexes. Rappelez-vous les années passées à essayer différents outils, les projets ratés, les hésitations devant de nouveaux types d’architectures et parfois votre perplexité devant certaines documentations. Restez simple ;-)
Choisissez les outils les plus simples qui peuvent être utilisés par tout le monde dans le groupe afin de permettre d’en apprendre davantage sur un certain sujet. Même s’il y existe des moyens plus modernes, ou plus largement utilisés pour répondre à une problématique, pensez à commencer votre enseignement par la solution la plus simple et la plus accessible à tous.
Par exemple:
-
Faites-les travailler sur les éditeurs Sublime ou Atom, à moins qu’elles soient déjà habituées à un outil différent (cela marche assez bien avec un éditeur de code basé sur le texte). Ils fonctionnent sur n’importe quel système d’exploitation et tout le monde peut partager ses raccourcis et sa configuration.
-
Utilisez la vielle syntaxe Hashrocket ({‘cle’ => ‘valeur’}) quand vous expliquez les hashes pour la première fois: c’est une syntaxe unifiée pour tous les hashes, quelque soit le type des clés. Il n’y a pas d’intérêt à connaitre deux syntaxes quand on apprend le concept, l’utilisation et les avantages des hashes. Plus tard, mentionnez la nouvelle syntaxe mais gardez l’ancienne au moins pendant un certain temps.
-
Passez les petites fonctionnalités lors des premiers pas. Vous voulez que votre groupe arrive au point où il peut écrire du code intéressant et utile. Beaucoup de fonctionnalités du langage, même certaines utilisées de temps en temps, sont inutiles pour arriver à cela. Pourquoi présenter les boucles For et While, les lambdas, l’opérateur “*”, les variables de classe, les assignations conditionnelles ou les arguments par défaut ? À la place, suivez la règle du 80/20 et enseignez en premier lieu du code simple. Amenez vos étudiantes à savoir écrire leurs propres outils. Vous pourrez ensuite présenter des fonctionnalités plus avancées du langage.
-
Commencez à enseigner les tests en utilisant ‘test/unit’ : les tests sont simplement des méthodes (ce qu’elles connaissent) et il n’y a pas d’ajout de configuration à prendre en compte. Ils vont simplement marcher aussi en Rails directement.
-
Mettez en place la première application Web en utilisant Sinatra, pas Rails. Présentez HTTP et comment les verbes correspondent aux méthodes ruby dans Sinatra. Puis, laissez-les porter leur application vers Ruby On Rails.
-
Présentez les routes Rails sans les ressources DSL. Laissez les étudiantes écrire chacune des routes. Cela leur permet de mieux comprendre les différences avec Sinatra, comment les routes mappent les verbes HTTP et les chemins vers un contrôleur, etc. Puis, plus tard, expliquez comment Rails gère les ressources pour vous faciliter la vie.
-
Présentez les migrations en en créant manuellement. N’utilisez pas de générateurs. Laissez les étudiantes numéroter leurs fichiers séquentiellement, comme aux premiers jours de Rails : cela leur permettra de comprendre le nommage des taches rake : ‘migrate:up’ et ‘migrate:down’. Laissez-les créer manuellement aussi les méthodes ‘up’ et ‘down’ au lieu d’utiliser la méthode ‘change’. Enfin, expliquez-leur pourquoi les fichiers de migration actuels sont aujourd’hui horodatés et pourquoi la méthode ‘change’ est apparue.
Partitionnez
N’essayez pas d’en enseigner trop en même temps. Réduisez les sujets. Quand vous pensez qu’ils sont assez simples, réduisez-les encore.
Prenez le temps de réfléchir sur ce qui nécessite le moins de connaissances pour être compris et qui n’a pas encore été abordé.
Au lieu de commencer avec une nouvelle application Rails au complet, envisagez d’avancer par étapes:
-
Apprendre comment écrire manuellement du code qui affiche une page statique en HTML et l’afficher dans un terminal
-
Apprendre comment sauvegarder le HTML dans un fichier, pour qu’il soit lisible par un navigateur.
-
Apprendre à utiliser ERB pour afficher le même HTML que précédemment.
-
Apprendre à utiliser Sinatra pour afficher le fichier, en introduisant HTTP.
-
Enfin, apprendre comment utiliser Rails pour afficher le fichier, en introduisant les routes et les contrôleurs.
Faites en sorte que vos étudiantes comprennent les bases de Ruby : ce que sont les méthodes, les blocs, les classes, les objets. Apprendre ce qu’est une méthode, comment écrire ses propres méthodes, comment les arguments sont passés et liés à des variables locales dans la portée de la méthode, ce qu’est une portée, … Tout cela devrait prendre du temps pour un nouveau venu.
Soyez certain de décomposer tout cela en petites étapes digestes. Gardez en tête que, en tant que développeur, vous ne connaissez pas juste tout cela. Vous “respirez” ces concepts. Vous les connaissez si bien que vous ne sauriez même pas comment bien les expliquer. Réfléchissez-y et essayez d’avancer avec les plus petites marches possibles, une à la fois.
Pour mieux y réfléchir, vous pouvez lire le chapitre “Learning to program” de notre livre Ruby For Beginners.
Répétez, souvent, différemment
Apprendre à programmer ne fonctionne qu’avec un travail de répétitions intenses. C’est un processus d’auto lavage de cerveau pour arriver à reconnaitre les différentes notions, comme la définition d’une méthode, et savoir ce que cela signifie.
Répétez vous encore et encore. Il est souvent utile de répéter les mêmes choses 3 fois, de manière différente.
Essayez d’établir des phrases phare faciles à retenir, que tout le monde dans le groupe garde en tête au fil du temps. Des phrases comme: En Ruby, toute méthode retourne une seule chose. Répétez ces phrases souvent, et demandez à vos élèves de les répéter.
Voici d’autres exemples:
-
4 éléments composent une méthode: un nom, un bloc de code, des arguments (entrées) et une valeur de retour (sortie).
-
Un bloc est une méthode sans nom, passée à une autre méthode.
-
En Rails, une ressource consiste en 7 routes.
-
Une migration représente un changement dans la structure de la base de données.
Utilisez des métaphores
Chaque personne tend à appréhender de nouveaux concepts d’une manière spécifique à elle.
Le but est donc de proposer plusieurs manières d’aborder un concept. Donnez des définitions précises, mais utilisez aussi des métaphores, des analogies et des images autant que possible. Essayez d’être amusant, tout en continuant de répéter des phrases précises et montrer comment fonctionnent les choses.
Par exemple, expliquez qu’ une route mappe un verbe HTTP et un chemin vers une action spécifique d’un contrôleur. Une action est une méthode d’instance d’une classe contrôleur mappée par une route. Puis, continuez avec une métaphore : Une route est comme le réceptionniste d’un hôtel : la demande du navigateur se dirige vers lui pour des informations, puis est envoyée à un certain étage, à un numéro de chambre specifique. Ou : Une route est comme un serveur dans un restaurant. Il prend votre commande, l’apporte au bon cuisinier, en fonction du plat demandé.
De plus, pensez à trouver des méthodes d’apprentissages plus créatives:
Comme devoirs, demandez aux étudiantes de venir avec une petite BD représentant une des métaphores vues ci-dessus. Autre possibilité, mettez en place un petit jeu de rôle où des personnes jouent le rôle de 3 ou 4 classes, se transférant des données par l’intermédiaire de feuilles de papier. Demandez leurs de venir avec de nouvelles idées pour représenter des morceaux de code
Demandez au groupe de venir avec des idées de représentation d’un morceau de code sur lequel vous avez travaillé ensemble. Laissez les identifier ce qui pourrait etre implémenté comme des classes: ça peut etre une ‘lampe’ qui a une méthode ‘enclencher’ pour etre allumée ou éteinte. Une fois, nous avons implémenté des classes ‘Gaufrier’, ‘Pate’ et ‘Gaufre’ et avons créé un jeu de role avec.
Observez et écoutez, soyez flexible
Puisque tout le monde est différent, il n’y aura jamais deux classes ou deux groupes identiques où tout le monde travaille de la même manière. Vous aurez besoin de vous adapter continuellement à vos étudiantes et à la nouvelle dynamique du groupe.
Quelque soit votre aisance à l’oral, essayez d’observer et d’écouter autant que possible. Le langage corporel de vos étudiantes vous informera sur leur ressenti, sur les résultats de l’explication, et comment poursuivre.
Essayez d’être flexible et ajustez vous au groupe, ainsi qu’a chaque étudiante individuellement. Expérimentez différents styles d’apprentissage, comme :
-
Faire des sessions ‘cours magistral’ où vous expliquez et démontrez des concepts sur un écran partagé ou avec un projecteur.
-
Faire travailler les étudiantes par paire sur de petits exercices.
-
Faire travailler le groupe sur un jeu de rôles ou sur des idées d’histoire ou de BD concernant un petit morceau de code.
-
Proposer des discutions sur des choses qui peuvent être représentées par des hashes, des tableaux imbriqués, des objets.
-
Organiser des recherches sur un sujet court et spécifique, pendant la semaine et le faire présenter pendant l’atelier
Vous pourriez vouloir faire plus d’ateliers de type cours magistral au tout début, pour expliquer des concepts de programmation basiques. Faites en sorte de faire de plus en plus de sessions d’exercices, où les élèves résolvent des exercices, idéalement par deux, mais aussi quelquefois par elles-mêmes. Organisez des sessions ou elles travaillent seuls, et restez de temps en temps à distance.
Soyez patient
Vous aurez besoin d’être extrêmement patient, spécialement si c’est votre premier groupe de suivi. Super méga patient.
Vous avez complètement internalisé toutes les connaissances qui font des livres entiers sur l’apprentissage de la programmation Toutes ces données (sits) dans votre tête, prêtes à être utilisées sans y penser plus que ça.
Les étudiantes qui n’ont jamais appris aucune notion de programmation seront quand à elles dépassées en peu de temps si vous essayez d’expliquer trop en trop peu de temps.
De plus, cela prend simplement du temps et demande de la répétition pour intégrer certains concepts, de les connaître et les comprendre assez pour les utiliser en pensant à autre chose (comme réfléchir aux concepts suivants, ou comment résoudre un certain exercice en utilisant ce concept).
Ne faites pas de suppositions
Même si c’est presque impossible, essayez de ne faire aucune supposition.
Quand quelqu’un rencontre des difficultés à comprendre pourquoi une certaine erreur apparait dans sont code, ne supposez pas qu’il a lu le message d’erreur attentivement, ou qu’il a jeté un œil à la backtrace. S l’erreur est liée à un tableau, ne supposez pas qu’ils aient compris la notion de tableau. Demandez leur ce qu’est un tableau.
Ne supposez pas qu’en ayant donné la définition d’un certain concept, comme MVC, et que les étudiantes peuvent le répéter, qu’elles peuvent aussi l’utiliser correctement maintenant. A la place, demandez quel morceau de code pourrait intégrer ce concept et essayez d’apporter des réponses utiles.
Résumez, donnez une image globale
Essayez d’entrer assez dans le détail pour que vos étudiantes comprennent chaque petite étape qui arrive quand un objet est instancié quand une méthode est appelée, quand des arguments sont passés et assignés à des variables locales et quand une valeur de retour est retournée.
Cependant, essayez de toujours englober les choses dans une image globale. Ayez une feuille de route générale pour le programme de votre groupe. Apres chaque semaine, résumez ce qu’elles ont appris et les avancées vis a vis de cette feuille de route.
En leur faisant faire leurs premiers pas dans une application Rails, à essayer de comprendre une fonctionnalité spécifique, n’oubliez pas de toujours résumer les choses et de parler de chaque étape par laquelle un cyle requete/reponse passe.
Soyez positif, encouragez les progrès
Tout le monde fait toujours du mieux qu’il peut. Quelque soit le progrès que vos étudiantes font, faites en sorte de toujours donner des retours positifs et complimentez leurs progrès.
Peut être que les choses vont moins vite que ce à quoi vous vous attendiez, ou qu’elles prennent une route différente. C’est toujours une avancée et il est super d’être allé aussi loin. Continuez de donner des retours positifs.
C’est d’autant plus important que certaines étudiantes ne se rendent pas compte des progrès quelles font.
Par exemple, après avoir présenté ce qu’est une méthode et expliqué comment elles sont définies et utilisées, les étudiantes pourraient se sentir un peu dépassées et confuses. Quelques semaines plus tard, elles vont définir et utiliser leurs propres méthodes comme si elles les avaient toujours connues. Comme les exercices actuels leur semblent compliqués, elles peuvent penser qu’elles n’ont fait aucun progrès.
Montrez leur leurs progrès et combien elles devraient être fières de ça.
Ayez peu d’opinions
Soyons réalise, la communauté Ruby valorise énormément les opinions fortes, et chacun a les siennes. C’est probablement bénéfique à la communauté dans son ensemble : beaucoup de discutions en découlent et tout le monde en sort enrichi personnellement.
Par ailleurs, un débutant ne devrait pas se limiter à l’opinion exclusive de quelqu’un. Au lieu de cela, il devrait découvrir plusieurs solutions possibles, entendre beaucoup d’opinions différentes, et essayer de se construire sa propre idée. C’est ce que vous avez fait au fur et à mesure des années d’apprentissage que vous avez suivi, tout comme la communauté entière.
Etant donné que vos élèves vous observeront et écouteront vos conseils d’une oreille très attentive, vous devriez essayer de prendre un peu de recul : montrez peu d’opinions.
Même si vous préférez un outil à un autre ou un éditeur à un autre, gardez le pour vous. A la place, donnez une liste des solutions possibles existantes et mentionnez les avantages et inconvénients. Expliquez le choix que vous auriez potentiellement fait pour le déroulement de l’atelier. Idéalement, laissez les décider de la solution la plus adéquate pour elles et demandez leur les raisons de leur choix.
Vous voulez que vos étudiantes restent curieuses et ouvertes d’esprit. Par exemple, même s’il vous arrive de vraiment détester Cucumber pour une raison X, si l’une de vos étudiantes s’y intéresse, vous devez alimenter sa curiosité et ne pas la décourager sur ce sujet. Si elles veulent utiliser Bootstrap, parce qu’un ami l’a utilisé avant, encouragez les à l’essayer même si vous pensez qu’il existe une meilleure option.
N’annulez jamais un atelier
Essayez autant que possible de ne jamais annuler un rendez-vous de groupe. Faites en sorte que quelqu’un prenne le relais si vous êtes en train de voyager où si vous êtes malade. Et faites tourner un atelier même s’il n’y a qu’une seule étudiante.
Cela aide à faire grandir le groupe et à avoir assez de mentors pour toujours avoir au moins 3 ou 4 étudiantes par semaine.
Cela donne de la stabilité, permet de la planification et crée de la confiance. Les participantes gagneront en motivation. Si vous annulez un atelier trop souvent, vous pourriez détruire le groupe.
Construisez une identité
Une fois que le groupe est plus ou moins établi, que chacun connaît les autres, a déjà participé a quelques ateliers et s’est amusé, demandez lui de se choisir un nom.
Laissez les participantes mettre en place une liste d’emails, un compte Twitter ou encore une page Facebook. Mettez en place une organisation Github avec elles, et ajoutez tout le monde comme administrateur. Utilisez des répertoires spécifiques pour les discussions, les documents et les exemples de code.
Si quelqu’un n’est pas confortable avec l’idée de committer publiquement, demandez à Github un compte organisationnel gratuit acceptant les répertoires privés.
Donnez des perspectives à long terme
Donnez à votre groupe des perspectives à long terme.
Expliquez aux étudiantes qu’elles seront bientôt capables d’écrire des scripts Ruby qui seront simples mais très utiles. Par exemple, si elles travaillent souvent avec des fichiers CSV, elles pourront écrire un script permettant d’extraire des données spécifiques au lieu de récupérer ces données manuellement et plus lentement.
Donnez leur une estimation de quand elles seront capables de créer leurs premières applications Web ou quand elles pourront postuler pour un emploi en tant que développeur junior.
N’oubliez pas de leur parler des Rails Girls Summer of Code, un projet qui a pour objectif de proposer des buts à long terme aux groupes de travail dédiés.
Venez avec un programme d’étude défini
Lorsque nous avons mis en place notre premier groupe de débutantes, nous sommes simplement venus avec quelques sujets différents, semaine par semaine. Il n’y avait pas beaucoup de bonnes ressources en ligne ciblées pour les débutants à cette époque la. Nous avons rapidement compris que c’était une erreur.
Au lieu de cela, il vaut mieux recommander un livre introductif à tout le monde, à lire chez soi. Il est important d’encourager vos étudiantes à lire d’autres livres et faire des tutoriels. Mais il faut faire en sorte que tout le monde ait au moins lu le livre que vous avez recommandé en introduction.
Puis, dans les ateliers hebdomadaires, suivez les mêmes sujets dans le même ordre que le livre. Expliquez les notions, répondez aux questions, et faites des exercices. Demandez à lire les quelques chapitres suivants chez soi, et proposez des exercices additionnels en guise de devoirs à la maison pour ceux qui le souhaitent.
Nous avons utilisé le livre de Chris Pine, Apprenez à programmer (https://pine.fm/LearnToProgram) dans deux groupes. Cela a fonctionné, mais quelques petites choses dans ce livre n’étaient pas idéales.
Par la suite, nous avons construit notre propre programme pour débutants et l’avons publié dans un livre: Ruby For Beginners. N’hésitez pas à l’utiliser. Bien entendu, tout retour ou amélioration sera bienvenu.
Concentrez-vous sur votre but
Nous vous recommandons de créer votre propre programme débutant, et de mettre en place des sessions individuelles afin de rendre le plus tôt possibles vos étudiantes autonomes en Ruby.
Cela requiert d’omettre beaucoup de fonctionnalités du langage pour se concentrer réellement sur le plus utile.
Dans nos groupes, nous nous efforçons à faire avancer nos élèves jusqu’au point ou elles peuvent écrire une simple application Sinatra et comprendre chaque fonctionnalité utilisée. Par la suite, nous proposons de plus petits objectifs, comme être capable de lire un fichier CSV et d’en filtrer les données.
Arrivez à ce point au plus tôt (en avançant bien évidemment aussi lentement que nécessaire pour leur faire comprendre les notions importantes). Cela va prendre quelques semaines, voire quelques mois, mais arriver à cela leur donnera la sensation d’être de vrais programmeurs pour la première fois : elles sont créé une application Web et ont entièrement copris ce qu’elles avaient fait.
Cela peut être une incroyable et motivante expérience à vivre.
Ne perdez pas de temps à présenter des fonctionnalités du langage dont vous aimeriez parler mais qui ne sont pas obligatoires pour votre objectif. Vous serez surpris de constater que l’on peut être productif pour écrire une application Sinatra tout en laissant de coté certaines parties de Ruby.
Encouragez à participer à d’autres évènements
Même pour les débutants, il est toujours intéressant de se joindre à un meetup Ruby local de temps en temps, de participer à un hackathon (proposez un hackathon sur un projet partagé) ou encore de suivre une conférence (n’hésitez pas à demander aux organisateurs des tickets gratuits, des réductions étudiantes, ou proposer une présentation contre des entrées).
Même si les débutantes ne comprennent pas complètement chaque conférence technique, cela peut être inspirant d ‘en écouter une, d’entendre des développeurs parler de leurs expériences ou simplement d’apprécier l’atmosphère sympathique et s’amuser.
Organisez des rencontres avec des invités Star et des experts
Quand un développeur connu est en visite dans votre ville, proposez lui de passer voir votre groupe et peut être même donner un rapide cours sur un sujet spécifique. Si votre groupe est intéressé sur un sujet que vous ne maitrisez pas, invitez un expert à diriger un atelier ou deux.
Avoir Konstantin Haase en intervenant exceptionnel, faisant une session introductive sur http n’a pas de prix. Pas seulement parce que les élèves vont avoir une super introduction au sujet, mais aussi car elles seront honorées d’avoir l’opportunité de rencontrer et suivre le cours d’un brillant développeur. Elles seront aussi heureuses de raconter cet évènement et d’en tirer de l’estime en elles mêmes.
Continuez à apprendre
Les mentors sont souvent des développeurs chevronnés et assez privilégiés pour se permettre de prendre du temps à coacher un groupe régulièrement.
Si vous faites partie de cette catégorie de personnes, faites en sorte de prendre du temps pour vous former sur certains sujets importants en tant que mentor. Voici quelques points de départ :
- Ainsi vous voulez etre un(e) allié(e) de Julie Pagano
- Resources pour alliés sur Geekfeminism
- Micro agressions de Nasma Ahmed
- Le syndrome de l’Imposteur sur Geekfeminism
- Menace du Stereotype sur Wikipedia, et How it works de xkcd.
- Homme blanc hétérosexuel de John Scalzi
- C’est partout de Tatsuya Ishida