Comment aider quelqu’un à trouver une erreur de programmation ?

N’oublions pas :
• Votre rôle sera d’aider les enfants à corriger leurs propres bugs, pas de les corriger pour eux.
• Vous êtes ici pour aider à découvrir la programmation, peu importe que tout ne soit pas parfait.
• Vive les erreurs : sans erreur à corriger, on ne peut pas progresser.

Comment s’y prendre lorsque je vois l’erreur en regardant le code ?

Voici quelques conseil pour que votre aide soit la plus utile possible au participant :
– Ne pas se saisir de la souris ou du clavier : laisser le participant faire les gestes, son cerveau apprend mieux.
– Ne pas jouer aux devinettes : quand on est coincé, se sentir bombardé de nouvelles questions n’aide pas.
– Donner de l’information pas à pas en laissant quelques secondes à chaque étape, par exemple :

  • « Ah oui, la valeur de la position du personnage animé est vraiment bizarre, n’est ce pas ? »
    → on ne fait que le diagnostic, et on s’assure qu’on soit ensemble en train de réfléchir au même problème
  • « On dirait que c’est la variable Y, la position verticale, son ordonnée donc, qui est boguée »
    → on essaye de lui apporter l’information qu’il lui manque, on utilise plusieurs formulations, ce qui fait une petite révision
  • « La variable Y est mal initialisée »
    → là on donne la clé, mais pas encore la façon de l’implémenter
  • « Il faut mettre la valeur Y à zéro au début du programme »
    → cette foi, on donne la solution, mais est-ce que cela fait du sens?
  • « Aller dans le menu « mouvement » »
    → on attend que le geste soit fait, et sinon on montre avec le doigt sur l’écran, toujours sans prendre la souris
  • « Choisir le bloc « donner la valeur… à y  » »
    → laisser le temps au regard de chercher, peut-être aussi qu’on est débloqué donc plus besoin d’aider
  • « Aller le placer ici »
    → en montrant du doigt le début du programme

– Faire ensuite le débriefing, en invitant les autres participants :

  • « C’est très intéressant, nous venons de voir comment débloquer quelqu’un qui a une erreur de programmation »
    → on est ici pour apprendre à apprendre, donc la situation était instructive
  • « Comme je jetais un regard neuf et extérieur à ce code, j’avais plus de chance de le trouver
    → celui qui trouve le bug n’est pas « supérieur » à celui qui le cherche
    → devant les enfants, le professionnel de l’éducation sera dans la position la plus facile: celui qui aide à débugguer
  • « Voici comment j’ai procédé… »
    → partage de cette petite méthode
  • « On parle de l’importance de l’erreur, qui ne fait pas d’erreur n’apprend plus rien de nouveau »
    → et c’est vraiment vrai!)

Et si je n’arrive pas à trouver l’erreur en regardant son code ?

Voici un cas qui arrive bien souvent, sinon ce serait trop facile :-). Pas de panique ! :
– demander de prendre la place de la personne devant la machine (ne surtout pas farfouiller par dessus son épaule en se penchant sur elle) : c’est une pause pour elle, les rôles vont s’inverser, personne ne sera en situation inconfortable.
– lui dire explicitement « je n’ai pas la solution, je vais chercher, essayons ».
– manipuler lentement la souris/clavier en expliquant chaque pensée et chaque geste, par exemple :

  • « Bon, c’est bizarre je ne vois plus le lutin. Est-il hors de l’écran ou devenu invisible ? »
    → questionner aussi l’apprenant, cela l’associe à la réflexion
  • « Je vais essayer de prendre le bloc « afficher le lutin » pour voir si… »
    → en décomposant chaque geste, et en verbalisant « je vais dans le menu… » etc.

– si c’est vraiment trop difficile de tout verbaliser, alors déclarer « bon, là j’ai besoin de farfouiller il me faut quelques minutes » et libérer la personne de sa posture d’observateur ; une fois le problème identifié, refaire en verbalisant devant lui le parcours de recherche effectué.
– si la solution vous apparaît, rendre la place devant la machine et passer au Cas 1 ; faire le débriefing de la méthode.
– la solution est peut-être de recommencer la programmation du début : faire remarquer que reprogrammer un problème, cela va très vite et le résultat est souvent plus élégant.
– ne pas passer plus de cinq minutes pendant la séance sur un même problème. Si le problème persiste, dire « tant pis pour le moment, nous ne sommes pas là pour programmer, mais apprendre à faire découvrir la programmation, même un projet non abouti peut-être très instructif ».

Et si on ne sait pas du tout comment faire ?

S’en féliciter 🙂 Nul besoin d’être encyclopédique, il s’agit juste de réfléchir ensemble, pour progresser dans la compréhension de la culture numérique et du monde qui nous entoure.
– Dire explicitement « je ne sais pas, mais nous allons chercher ensemble la réponse » et guider les participants dans la recherche : aller ensemble sur Wikipédia et suggérer des mot-clés, sur https://pixees.fr ou https://intertices.info, voir comment vous recherchez la solution est bien plus instructif que juste donner la réponse
– ne pas hésiter à retourner sur la formation en ligne, revoir ensemble un grain et en discuter

Si la difficulté persiste :
– très simplement, rediriger la question vers le bureau d’accueil https://pixees.fr?ba, cela montrera qu’il y a un vrai support. À terme, le but est que les participants puissent entre eux trouver les réponses à leurs questions.
– on a aussi parfaitement le droit de ne pas répondre de suite et de dire, « okay, je garde la question et y répondrai à la prochaine séance ou par mail ».