En parcourant mes anciennes slides, je suis retombé sur un sujet totalement inconnu pour moi au départ mais qui m’a apporté son lot de réflexions quand je l’ai étudié et appliqué pour en faire une présentation orale.

L’envie m’a pris de vous le faire découvrir également.

Introduit par le livre The Pragmatic Programmer en Octobre 1999, dans lequel un programmeur utilise un canard en plastique pour lui énoncer ses problèmes algorithmiques.

Le Rubber Duck Debugging est une méthode insolite mais sacrément efficace auprès des développeurs pour résoudre des problèmes.

Elle comporte de nombreux avantages.

En adoptant une explication simplifiée, cela permet d'avoir un état d’esprit de débutant sur le problème.

Il existe même un terme en japonais pour définir cet état d’esprit.

“Shoshin”

Cela implique d’avoir une attitude d’humilité que l'on doit entretenir tout au long de son parcours, et quel que soit son niveau.

Surement, l'appliquez-vous déjà sans le savoir ?

En prenant le problème ligne par ligne, fonctionnalités par fonctionnalités, le développeur se force à étendre sa capacité à se faire comprendre.

C’est comme s'il s’affranchissait de tout jargon technique.

Un retour à un langage plus naturel et basique.

Pensez-y, si nous ne pouvons pas l’expliquer clairement à un enfant de 6 ans, nous ne pourrons pas le comprendre nous-même.

Le Rubber Duck, pendant ce temps, invariable, vous fixe.

Voyez le comme un compagnon de clavier toujours présent, qui peut d'ailleurs être totalement autre chose qu’un canard en plastique, mais sûrement pas au point d’en faire votre Wilson, il est votre allié quand vous en ressentez le besoin.

Oui, parce qu’au final, avoir une oreille de disponible à qui énoncer le problème, nous pousse, développeurs, à adopter, des méthodes d'énonciation de problèmes plus compréhensibles, et usant du Shoshin, cela nous ouvre à l’innovation.

Vous serez amenés à faire des erreurs dans votre code, soit parce que vous étiez moins au top ce jour là, soit parce que vous avez simplement le nez dedans depuis plusieurs mois.

Peu importe l'erreur, ça peut être long et fastidieux de savoir d'où elle vient.

Combien se rendent compte de leurs erreurs de code quand ils racontent à une autre personne comment fonctionne leur programme ?

Bien sûr, nous pouvons minimiser l’erreur, grâce notamment à d'autres outils et méthodes de développement. Mais nous ne devons pas exclure la possibilité d’une erreur, et il faut la voir comme une opportunité de monter en compétences et un levier d’apprentissage, et non comme quelque chose qui nous fait peur ou nous fait sentir misérable auprès des autres.

En s'entraînant, nous arriverons à clairement expliquer ce que nous faisons, puisque nous serons en mesure de comprendre comment nous le faisons.

Automatiquement, nous bénéficierons d’autres biais pour arriver à la solution.

Et grâce à cela, nous en tirerons tous les avantages afin de devenir de meilleurs développeurs.