Qu'est-ce qui qualifie quelqu'un pour être mentor ?
Puis-je mentorer un langage pendant que je l'apprends encore ?
Puis-je mentorer plus d'un langage ?
Dois-je essayer de mentorer toutes les solutions de la file d'attente ?
Que faire si une solution attend dans la file d'attente depuis des jours, voire des semaines ?
Que faire si je n'ai rien à suggérer sur une solution ?
Dois-je mentorer un exercice que je n'ai jamais résolu ?
Dois-je mentorer un exercice que j'ai résolu, mais dans un autre langage ?
Suis-je obligé de mentorer une solution une fois que je l'ai vue ?
Que faire si l'apprenant ne comprend pas après que j'ai expliqué quelque chose plusieurs fois ?
Comment réagir si l'apprenant se braque sur mes suggestions ?
L'apprenant doit-il avoir le dernier mot, même si je le trouve dans l'erreur ?
Comment formuler au mieux une suggestion ?
Dois-je imposer des conventions de formatage, de commentaires et de nommage ?
Qu'est-ce qui qualifie quelqu'un pour être mentor ?
Pas besoin d'être expert dans un langage pour mentorer ce langage.
Il suffit d'être un peu moins novice que la personne que tu mentors.
Si, dans une solution, quelque chose te semble pouvoir être fait autrement, tu peux le suggérer.
Ce n'est pas nécessairement une meilleure façon de faire, juste une alternative idiomatique.
Cela laisse à l'apprenant le choix d'utiliser la suggestion ou non, mais au moins il dispose de plus d'options.
Puis-je mentorer un langage pendant que je l'apprends encore ?
Idéalement, on n'arrête jamais d'apprendre un langage, même celui qu'on connaît déjà.
Certains langages publient une nouvelle version toutes les quelques semaines ou tous les quelques mois.
Il peut y avoir de nouvelles fonctionnalités du langage à apprendre, mais aussi des fonctionnalités existantes que tu ignores.
Il arrive qu'un apprenant utilise une fonctionnalité que tu vois pour la première fois.
Le mentorat peut donc être un bon moyen d'en apprendre plus sur un langage.
Puis-je mentorer plus d'un langage ?
Tu peux mentorer autant de langages que tu veux, tant que tu te sens à l'aise.
Tu peux très bien mentorer plusieurs langages dans lesquels tu es à l'aise, ainsi qu'un langage que tu apprends encore.
Dois-je essayer de mentorer toutes les solutions de la file d'attente ?
Si, sur le moment, tu ne trouves rien de substantiel ou de constructif à dire sur une solution, il vaut peut-être mieux pour l'apprenant laisser la demande de mentorat à un autre mentor, même si l'apprenant devra attendre plus longtemps une réponse.
Que faire si une solution attend dans la file d'attente depuis des jours, voire des semaines ?
Si l'apprenant a posé une question précise à laquelle tu ne peux pas répondre, tu peux quand même la laisser à quelqu'un qui saura y répondre.
Sinon, la solution concerne peut-être un exercice qui a été difficile pour toi, que tu n'as pas résolu, ou que tu as résolu sans avoir le sentiment de très bien t'en sortir.
Dans ce cas, tu peux parcourir la solution pour voir si tu peux en apprendre quelque chose.
Si oui, tu peux remercier l'apprenant pour ce que tu as appris de sa solution.
Tu peux aussi demander à l'apprenant de t'expliquer sa solution.
C'est une sorte de « mentorat inversé », mais certains apprenants seront ravis d'expliquer leur solution si on le leur demande avec politesse et respect.
Tu peux alors leur demander s'ils ont envisagé une autre approche et pourquoi ils ont choisi celle-ci.
Ou bien, tu ne comprends toujours pas la solution dans son ensemble, mais tu repères des points que tu peux traiter.
Par exemple, tu peux leur suggérer d'utiliser des noms explicites pour les paramètres de la fonction, s'ils ont simplement utilisé n ou m.
Si aucune de ces options ne te met à l'aise, tu peux laisser la demande sans réponse.
Le mentorat est bénévole.
Ce n'est pas parce que tu mentors un langage que tu dois mentorer tous les exercices de ce langage.
Que faire si je n'ai rien à suggérer sur une solution ?
Tu peux très bien dire ce qui te plaît dans une solution.
En fait, dire ce qui te plaît précisément dans une solution est une bonne façon de commencer n'importe quel échange de mentorat.
Ensuite, si tu n'as pas de suggestion d'approche alternative pour l'exercice, tu peux simplement dire à l'apprenant : « Bien joué ! »
Si l'apprenant a soumis plus d'une itération, tu peux souligner en quoi la plus récente est une amélioration.
Dois-je mentorer un exercice que je n'ai jamais résolu ?
Il arrive que la lecture de la solution d'un apprenant te donne envie de résoudre l'exercice toi-même, surtout si l'approche utilisée fait paraître l'exercice plus simple que les approches que tu avais envisagées.
Une fois l'exercice résolu, si la demande de mentorat qui t'a inspiré n'est plus disponible, tu seras au moins prêt pour la prochaine fois.
Dois-je mentorer un exercice que j'ai résolu, mais dans un autre langage ?
Étant donné que ce qui est idiomatique dans un langage ne l'est pas forcément dans un autre, il vaut mieux avoir résolu l'exercice dans le langage que tu mentors.
Si les solutions se ressemblent beaucoup d'un langage à l'autre, et que tu connais assez bien les deux pour savoir ce qui est idiomatique dans chacun, transposer une solution d'un langage à l'autre ne devrait pas prendre longtemps.
Si la demande de mentorat n'est plus disponible après la transposition de la solution, tu seras au moins prêt pour la prochaine fois.
Suis-je obligé de mentorer une solution une fois que je l'ai vue ?
Tu peux regarder une solution et te rendre compte que tu ne veux pas la mentorer, pour plusieurs raisons, notamment :
- L'apprenant a peut-être posé une question dont tu ne connais pas la réponse.
- Le code est peut-être tellement verbeux et/ou confus que tu ne sais pas par où commencer une critique.
- Le code peut indiquer que l'apprenant est un parfait débutant qui aura besoin de beaucoup de conseils de base, pour lesquels tu n'as ni le temps ni la patience.
- Le commentaire de l'apprenant peut laisser entendre qu'il sera désagréable ou pénible à côtoyer.
Rien ne t'oblige à cliquer sur le bouton « Commencer le mentorat » si tu estimes que cette demande de mentorat n'est pas pour toi.
Que faire si l'apprenant ne comprend pas après que j'ai expliqué quelque chose plusieurs fois ?
Il peut arriver qu'un apprenant semble presque refuser obstinément de comprendre tes explications.
Si tu as le sentiment d'avoir épuisé toutes les façons d'expliquer quelque chose, tu peux décider de conclure la discussion en suggérant à l'apprenant de soumettre à nouveau sa demande de mentorat, pour qu'un autre mentor, qui saura peut-être mieux expliquer les points difficiles, la prenne en charge.
Il arrive qu'un apprenant explique avoir utilisé une approche plus laborieuse que nécessaire pour mieux apprendre une fonctionnalité du langage, même si cette fonctionnalité n'est pas la mieux adaptée à l'exercice.
Comme Exercism est une plateforme d'apprentissage et non un site de compétition de programmation, c'est une raison tout à fait défendable de ne pas utiliser l'approche la plus élégante ou la plus efficace.
Tu peux faire quelques suggestions sur la façon dont ils ont mis en œuvre leur approche, si tu vois qu'ils auraient pu l'implémenter de manière plus idiomatique.
Dans tous les cas, tu peux leur suggérer de soumettre une nouvelle itération en tenant compte des retours, ou de mettre fin à la discussion pour libérer un créneau de mentorat.
Un apprenant peut adhérer à un paradigme de programmation qui n'est pas le mieux adapté au langage ou à l'exercice.
Par exemple, il peut vouloir systématiquement utiliser le paradigme orienté objet et fragmenter une solution relativement simple et directe en une petite explosion de classes au flux de contrôle labyrinthique à travers de multiples méthodes.
Dans la mesure où l'apprenant suit le paradigme de façon dogmatique, il est généralement vain de tenter de le convaincre d'adopter une autre approche.
Tu peux essayer, et il répondra peut-être à ta suggestion, mais si l'apprenant campe sur ses positions, mieux vaut passer à autre chose.
L'apprenant peut rejeter catégoriquement une suggestion.
Par exemple, tu peux suggérer d'utiliser reduce au lieu de map et join, puisque reduce ne fait qu'une seule itération au lieu d'une pour map et d'une autre pour join.
Mais l'apprenant peut refuser, parce qu'il trouve map et join plus lisibles.
Tu peux tout à fait admettre avec l'apprenant que map et join peuvent être plus lisibles que reduce.
Tu peux lui suggérer qu'il sera peut-être plus à l'aise avec reduce après un peu de temps pour s'y habituer, et qu'il n'y a rien de mal à utiliser map et join.
Tu peux reconnaître ce que l'apprenant dit de juste, et tu peux aussi tenter de corriger toute idée fausse ou exagération qu'il aurait pu exprimer.
L'apprenant doit-il avoir le dernier mot, même si je le trouve dans l'erreur ?
Par exemple, tu peux suggérer à un apprenant de ne pas utiliser de nombres magiques comme 60 et 24 pour résoudre l'exercice Clock, mais plutôt de les définir comme des constantes aux noms explicites.
L'apprenant peut répondre que, vu le contexte, on voit bien ce que représentent 60 et 24.
Tu as fait ta suggestion et l'apprenant l'a écartée.
Tu n'as peut-être rien à y gagner, et peut-être de la bienveillance à y perdre, en discutant.
Pour proposer une alternative qui n'est pas forcément meilleure, tu peux commencer par « Une autre approche serait... »
Par exemple : « Une autre approche serait d'utiliser every avec includes. »
Si tu présentes une fonctionnalité du langage que l'apprenant n'a pas utilisée dans sa solution (comme every ou includes), il est bon d'ajouter un lien vers une documentation qui l'explique.
Une autre façon d'introduire une suggestion peut être « Envisage peut-être de... »
Par exemple : « Envisage peut-être d'utiliser la syntaxe de propagation au lieu de split(). »
Si tu es convaincu que l'apprenant doit utiliser une alternative, tu peux retirer le « peut-être » et commencer par « Envisage de... »
Par exemple : « Envisage d'utiliser un argument par défaut. »
Pour une série de suggestions, tu peux varier la façon dont chacune est introduite.
Les puces sont un moyen efficace d'énumérer ce qui te plaît dans une solution.
Elles paraissent moins amicales lorsqu'elles servent à lister des suggestions.
Formuler les suggestions de façon décontractée et conversationnelle peut les rendre plus faciles à envisager et à accepter pour l'apprenant.
Un mot qu'il vaut probablement mieux éviter quand on propose une suggestion est « devrais ».
Par exemple : « Tu devrais utiliser un argument par défaut. »
Employer des mots comme « devrais » ou « dois » peut sembler autoritaire.
Les mentors seront probablement en désaccord sur le moment et la fermeté avec lesquels aborder des questions comme le formatage du code, les commentaires et les conventions de nommage.
D'un côté, tu peux vouloir amener l'apprenant à réfléchir à ces questions très tôt, avec des exercices comme Two Fer, avant qu'il ne prenne de mauvaises habitudes.
Ou tu peux préférer ne pas intimider un débutant avec toutes ces considérations de bienséance.
De l'autre côté, les apprenants qui font les exercices plus avancés connaissent peut-être déjà ces conventions mais choisissent de les ignorer pour se concentrer sur la tâche du moment.
Ils peuvent trouver qu'insister sur les conventions relève du pédantisme.
Si un langage dispose d'un ou plusieurs formateurs ou linters, il peut être bon de choisir un exercice pour les présenter.
Sinon, si la violation d'une convention particulière est vraiment grave, tu peux vouloir la signaler partout où elle se produit.
Les mentors peuvent diverger sur ce qui est considéré comme « vraiment grave ».
