Réinventer pour 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", 3 fois "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 coach 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.

🚨 Attention spoiler alert! 🚨

Le kata Diamond en est la parfaite illustration. L'objectif est de construire un losange, caractérisé par une dimension passée en paramètre (cf. infra). 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.

• Dimension 1 : tout roule, il suffit de renvoyer le résultat attendu "en dur".

• Dimension 3 : tout roule encore, un simple branchement if pour renvoyer deux résultats différents selon la dimension (1 ou 3).

• Dimension 5 : étape de triangulation (même comportement mais valeurs différentes afin de faire émerger l'implémentation). Euh… bon on va rajouter un autre branchement et puis on verra après !

• Dimension 7 : euh… on va continuer comme ça longtemps ?

Dim. 1      Dim. 2      Dim. 3
*             *             *
            * * *         * * *
              *         * * * * *
                          * * *
                            *

On voit bien que la démarche ne mène à rien. Vouloir refactorer le code à ce stade pour faire passer tous les tests avec une seule implémentation, c'est avoir résolu le problème dans son intégralité. À supposer qu'on y parvienne, le TDD n'aura nullement facilité (guidé) le développement.

Et c'est normal : ce kata est un piège. Le chemin le plus évident (faire varier la dimension) se révèle être la face Nord de l'Everest 🏔. Il faut donc imaginer un chemin de pente plus douce, un chemin plus progressif — mais nous n'en dirons pas plus pour ne pas déflorer le sujet : faites le kata !

🚨 Fin de spoiler alert. 🚨

Au risque d'être un rien 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 développeurs et développeuses touchent du doigt la difficulté par eux-mêmes. En d'autres termes, je les pousse à l'erreur, je les pousse au crime 🔪😇. Une fois la difficulté éprouvée et la question formulée, la réponse que j'y apporte 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).

À la semaine prochaine 👋 !

(*) Ça marche aussi pour une personne du sexe féminin #2022.