Faites des erreurs !

Que vient faire Warren Buffet dans cette affaire ? Vous allez vite comprendre.

"On apprend de ses erreurs" : nous sommes tous et toutes acquis à cette idée, même si c'est parfois un peu dur à digérer sur le moment 🥲 Warren Buffet aurait d'ailleurs précisé, non sans malice : "C'est bien d'apprendre de ses erreurs. Il vaut mieux apprendre des erreurs des autres".

Pas con, le mec.

Donc l'erreur, c'est utile. Cela signifie que si elle advient, il faut en tirer les leçons. Mais devrions-nous pour autant la souhaiter ? Faut-il aller jusqu'à la provoquer ? 😵‍💫

Ma réponse est "oui". Enfin, "oui" dans une certaine mesure. Dans un cadre sécurisé, l'erreur est souhaitable car elle permet de prendre conscience de la difficulté et nous incite à formuler le problème que l'on cherche à résoudre. Car au final, pourquoi le Test-driven development (TDD) ? Pourquoi la programmation fonctionnelle ? Trop souvent, on va vers ces notions parce qu'il est établi qu'elles constituent de bonnes pratiques, sans pour autant en ressentir soi-même intimement la nécessité.

Il faut avoir passé 4 heures à chercher un bug et tout détricoter pour comprendre la nécessité d'un feedback rapide sur le code (d'où l'importance du typage, d'où l'importance du TDD). Il faut avoir introduit des régressions en prod pour comprendre l'importance de programmer sans effet de bord et apprendre à écrire des fonctions pures non parce qu'on le doit, mais parce qu'on le veut.

Mais allons plus loin : idéalement, il faudrait même être sur le point de réinventer un concept pour en comprendre réellement la nécessité. Galilée l'a dit mieux que personne :

"Vous ne pouvez rien enseigner à un homme, vous ne pouvez que l'aider à le découvrir en lui-même."

Il n'y a donc pas d'apprentissage sans erreur, ou en tout cas pas d'apprentissage sans tâtonnement, et le formateur doit en tirer profit en favorisant sa survenue. Mais pas n'importe comment bien sûr. Hors de question de faire ça sur du code de prod, les exercices de code (kata) sont là pour ça.

Le kata Diamond en est la parfaite illustration. Après quelques exercices réussis en TDD (FizzBuzz, Leap Year, Fraction…), la confiance vient, avec l'idée qu'il n'y a qu'à se laisser guider par la méthodologie pour que les choses se fassent d'elles-mêmes. Et là, c'est le drame. Je ne vous en dis pas plus – à vous d'en faire l'expérience, mais ce kata est un piège. Un piège essentiel pour vraiment comprendre ce qu'est le TDD, et ce qu'il peut vous apporter.

Au risque d'être catégorique, je dirais donc que tant qu'il n'y a pas eu erreur, il n'y a pas eu apprentissage. Au poker, on parle de la "chance du débutant", en informatique on dit que "ça tombe en marche". Dans les 2 cas, on n'a rien appris.

Lors des séances de coaching que je propose, je fais ainsi en sorte que les développeurs touchent du doigt la difficulté par eux-mêmes. En d'autres termes, je les pousse à l'erreur. Une fois la difficulté éprouvée et la question formulée, la réponse devient évidente.

Mais là encore, quelqu'un l'avait dit bien avant moi :

"Si j'avais une heure pour résoudre un problème, je passerais cinquante-cinq minutes à définir le problème et seulement cinq minutes à trouver la solution" (A. Einstein).