L’entraînement délibéré est une pratique issue du sport de haut niveau où l’entraînement se concentre sur les parties où l’athlète doit progresser à l’aide d’exercices bien identifiés. Par exemple en basket, il peut s’agir de répéter un certain type de tir jusqu’à obtenir le niveau désiré.
Cet article parle de l’absence d’entraînement délibéré des travailleur·e·s du savoir : certaines personnes s’entrainent avec des exercices mais plutôt de manière ponctuelle, par exemple pour maîtriser un nouveau domaine, alors que d’autres pensent que de pratiquer leur discipline est suffisant.
Cela m’a fait réfléchir aux pratiques que je connais dans le développement.
Je vous préviens : je n’ai d’idée magistrale à vous proposer, plutôt des insatisfactions et des pistes.
Trouver un équivalent
Les exercices que je croise le plus souvent dans le développement sont les katas et les problèmes spécifiques aux entretiens d’embauche.
J’ai déjà décris mes frustrations avec les premiers. Ils sont pensés pour permettre d’introduire une idée ou une pratique bien précise, mais je ne pense pas qu’ils permettent de progresser très loin (en tous cas ceux que je connais).
Les seconds, comme ceux-ci, sont un autre cas : certains couvrent des sujets fondamentaux d’algorithmique (écrire un arbre binaire…), d’autres sont plutôt des puzzles où la connaissance nécessaire pour les résoudre n’est utile qu’à la résolution de ce type de problème. Les exercices de l’advent of code sont à mettre pour moi dans ce même groupe.
Apprendre par la répétition en développement ?
En développement, je ne sais même pas si un équivalent direct de l’entraînement délibéré est possible. L’idée de l’entraînement délibéré est de progresser en répétant un même geste, alors que dans le développement, où l’activité principale est la conception, il est difficile pour une même personne de concevoir deux fois la même chose : lorsqu’on répète l’exercice une seconde fois on va probablement beaucoup s’appuyer sur la première car on sait déjà comment s’y prendre.
Je ne pense pas que la répétition soit totalement inutile, elle peut permettre d’explorer d’autres approches, mais une partie de la réflexion et de l’exploration ne sera pas faite en double.
Et au delà d’une ou deux répétitions, je pense que l’exercice ne permet plus d’apprendre grand chose.
Si on ne peut pas avoir d’équivalent direct, que peut-on faire ?
Au moins un entraînement plus réfléchi ?
Une manière de s’entraîner, mais j’ai l’impression souvent peu structurée, est de faire des mini-projets, par exemple en réimplémentant des versions simplifiées outils qu’on a l’habitude d’utiliser (comme un ORM ou un moteur de tâches).
Les exercices en question sont assez longs (plusieurs heures au minimum), le cadre n’est donc plus le même. À l’inverse, la durée permet de pratiquer un ou des sujets de manière plus longue qu’un kata.
L’aspect répétition est perdu, mais au moins cela fournit une manière de progresser sur un sujet.
Mais à l’inverse du sport où les exercices sont répertoriés, ce n’est pas le cas pour les mini-projets.
Une certaine expérience du domaine du projet permet de se faire une idée de quel domaine il va mettre en jeu, par exemple qu’un moteur d’expression régulière devrait permettre de s’exercer au parsing.
Cela nécessite de connaître un peu le domaine, et même dans ce cas cela ne garantit pas que tel problème est le mieux adapté.
L’autre élément difficile à savoir est quelles sont les parties du projet qui fournissent le meilleur apprentissage pour un temps et un sujet donné.
Par exemple certains projets permettent d’apprendre beaucoup dans leur phase initiale, et le reste est “juste du code”, alors que pour d’autre les phases les plus intéressantes se passent plus tard lors de l’implémentation de fonctionnalités plus avancées. Avoir cette information au début permet d’éviter le risque de s’arrêter trop tôt ou trop tard.
Ma suggestion, pour les personnes qui développent des mini-projets et qui veulent en parler, serait donc de documenter ces éléments (durée du projet, domaines couverts, moments où on apprend le plus de choses) pour que d’autres puissent en profiter.
À moins que vous n’ayez une meilleure idée ?