Indiquer les erreurs ne traumatise pas :-)
Sauf si l'enseignant est un crétin (étant issu d'une famille d'enseignant, et n'ayant presque fréquenté que cette rare durant mon enfance, je confirme qu'il y en a un paquet).
Nous avons plus de facilités à progresser sur nos points positifs que sur nos points négatifs. Donc les méthodes de « correction d'erreur » sont moins efficaces que les méthodes « d'amplification de succès ». Schématiquement.
Lorsque c'est bien fait, l'apprenant tente d'améliorer ses succès. Donc en gros il corrige ses erreurs qui ne sont pas signalées comme telles puisque par définition ce ne sont pas des erreurs, mais des apprentissages pas encore intégrés.
Par exemple un développeur qui doit apprendre à mettre le code en forme correctement, avec des commentaires efficaces, utiliser un SVN, etc : on va lui indiquer que tel et tel points sont déjà presque bons. On ne lui explique pas tout ce qui ne colle pas. Il est en phase de prise en main il est normal qu'il y ait un paquet de choses de travers. Il est également normal qu'il ne comprenne pas pourquoi tel autre point est important, donc lui signaler que c'est mal fait ne fonctionne pas efficacement.
Au fil du temps il va apprendre à réaliser les points suivants.
Au final il saura tout faire correctement. Avec des affinités pour certaines choses (il sera très efficace dessus) et pas pour d'autres (il saura faire ce qu'il faut, sans plus).
[^] # Re: Scores
Posté par Kerro . En réponse au journal Un jeu pour enfants : Les Jeux d'églantine. Évalué à 2.
Indiquer les erreurs ne traumatise pas :-)
Sauf si l'enseignant est un crétin (étant issu d'une famille d'enseignant, et n'ayant presque fréquenté que cette rare durant mon enfance, je confirme qu'il y en a un paquet).
Nous avons plus de facilités à progresser sur nos points positifs que sur nos points négatifs. Donc les méthodes de « correction d'erreur » sont moins efficaces que les méthodes « d'amplification de succès ». Schématiquement.
Lorsque c'est bien fait, l'apprenant tente d'améliorer ses succès. Donc en gros il corrige ses erreurs qui ne sont pas signalées comme telles puisque par définition ce ne sont pas des erreurs, mais des apprentissages pas encore intégrés.
Par exemple un développeur qui doit apprendre à mettre le code en forme correctement, avec des commentaires efficaces, utiliser un SVN, etc : on va lui indiquer que tel et tel points sont déjà presque bons. On ne lui explique pas tout ce qui ne colle pas. Il est en phase de prise en main il est normal qu'il y ait un paquet de choses de travers. Il est également normal qu'il ne comprenne pas pourquoi tel autre point est important, donc lui signaler que c'est mal fait ne fonctionne pas efficacement.
Au fil du temps il va apprendre à réaliser les points suivants.
Au final il saura tout faire correctement. Avec des affinités pour certaines choses (il sera très efficace dessus) et pas pour d'autres (il saura faire ce qu'il faut, sans plus).