Idée principale

Le travail d'encadrement est le même que celui qu'un développeur expérimenté fait auprès d'un débutant : redire pourquoi un fichier ne doit pas tout contenir, pourquoi une couche ne doit pas en connaître une autre, pourquoi on ne charge pas toute la donnée, pourquoi il faut écrire les tests et pourquoi il faut les relancer. On donne une capture d'écran d'un composant, et ce qui revient est une interprétation simplifiée qu'il faut reprendre.

Ce qui diffère est ce que cet effort achète. Encadrer un junior est un investissement : les mêmes remarques ne se répètent pas indéfiniment, parce que la personne accumule. Un assistant n'accumule rien de lui-même — la correction vaut pour la session, pas pour la suivante, et la même dérive revient sur la fonctionnalité d'après.

L'encadrement d'un assistant n'est donc rentable que s'il change de support : ce qui serait dit à un junior doit être écrit une fois dans le cadre que l'assistant relit — fichiers d'instructions, conventions, catalogue de patterns. Redire à chaque fois est le régime coûteux ; écrire est le régime qui capitalise.

Pourquoi c'est important

Cela corrige la lecture spontanée de la relation. Ceux qui décrivent l'assistant comme un junior très rapide en tirent d'ordinaire une conclusion optimiste — il suffit de bien l'encadrer — alors que le mécanisme qui rendait l'encadrement supportable a disparu.

Cela indique aussi où passe le temps réellement gagné : pas dans la production de code, qui est effectivement plus rapide, mais dans la répétition d'un encadrement qui ne se capitalise pas tant que rien ne l'écrit.

Nuances et limites

L'analogie a ses limites : contrairement à un junior, l'assistant ne se lasse pas d'être repris, ne perd pas confiance et ne coûte pas une carrière. La comparaison sert à situer la charge d'encadrement, pas à décrire la relation.

Et l'écriture du cadre a elle-même un coût, qui ne se justifie que sur un travail répété. Pour un outil construit en une soirée et abandonné le lendemain, redire est moins cher qu'écrire.

Questions ouvertes

• Quelle part de ce qu'un développeur expérimenté transmet à un junior est effectivement formalisable dans un fichier d'instructions, et quelle part ne tient que dans la discussion sur un cas précis ?