Les juniors n'apprendront plus rien

Quand j'ai découvert Extreme Programming, il y a un peu plus de 20 ans, j'ai été emballé pour plein de raisons. Mais il y avait une pratique à laquelle j'avais beaucoup de mal à adhérer : le pair programming.

Pour un développeur, ne pas être seul, en totale maîtrise avec son écran et son clavier, c'est contre-intuitif.

Comment ça ? Quelqu'un va rester en permanence à côté de moi et me regardera écrire mon code ? Ou, pire, c'est moi qui vais rester là à regarder l'autre coder ? C'est complètement improductif !

En plus, si les 2 personnes ont à peu près le même niveau, ça pourrait fonctionner. Mais imaginez une paire senior-junior. Le senior aura toutes les réponses et le junior n'apprendra rien. Pour progresser dans ce métier, il faut se confronter soi même aux problèmes. Si on est en paire, les juniors ne progresseront plus.

Cet argument sur l'apprentissage des juniors, je l'ai moi-même formulé quand l'organisation dans laquelle je travaillais s'est lancée en 2004 dans Extreme Programming.

C'est exactement le même argument que l'on voit aujourd'hui un peu partout comme un risque majeur de l'utilisation de l'IA. J'avais tort à l'époque, et ceux qui noircissent la situation actuelle ont probablement tort aussi.

Le raisonnement avancé par beaucoup de monde est le suivant (en version courte) :

• Apprendre à développer des logiciels, c'est écrire du code, faire des erreurs, comprendre ses erreurs et progresser
• Comme l'IA écrit désormais le code, on ne passe plus par cette phase d'apprentissage et donc on ne monte pas en compétence

Il y a une vérité : beaucoup de code n'a plus aucune raison d'être écrit à la main car on a désormais des outils qui vont écrire du code à partir de quelques instructions en langage humain.

Donc, effectivement, si l'apprentissage c'est principalement faire des erreurs en écrivant du code, ça sent le sapin.

Moi, j'ai l'impression qu'on nous présente une fausse idée de cet apprentissage. Personne n'est jamais devenu expérimenté en développement logiciel en produisant du code.

C'est en forgeant qu'on devient forgeron

Ok, mais vous en connaissez encore beaucoup des forgerons aujourd'hui ?
Si on a un système industriel qui produit du code à la chaîne, pourquoi continuer à forger à la main ?

Donc, ouais, si vous voulez former des forgerons, il va falloir les faire forger et leur interdire les outils qui feront une grande partie du boulot à leur place.

Mais les forgerons de 1850 n'auraient pas pu construire le Crystal Palace. Donc l'objectif est peut être ailleurs que de former des gens à progresser par essai/erreur dans l'écriture de code.

Le truc trop souvent passé sous silence, c'est que développer un logiciel, c'est très largement une activité d'apprentissage à part entière :

• comprendre l'environnement des utilisateurs
• essayer diverses approches pour trouver celle qui s'adapte le mieux à cet environnement
• imaginer comment découpler deux parties de code intimement liée
• trouver des points communs et des généralisations en observant diverses parties d'un système
• ...

Impossible de faire une liste exhaustive.

Le code produit dans tout ça ? Ce n'était déjà pas l'essentiel et ça va devenir un détail.
L'important, c'est la connaissance que l'on crée et que l'on manipule.

Try treating programming as a learning activity that throws off running code as a byproduct
Kent Beck

Tout ça demande quelques remises en question. Mesurer l'activité de développement logiciel par la production de code, c'est facile et sans intérêt. Mesurer la connaissance produite, c'est plus important, et c'est un peu plus compliqué à mesurer.

A mon avis, 2 axes vont être fondamentaux dans la formation des producteurs de logiciel de demain :

• la capacité à comprendre pourquoi on construit un logiciel et pas un autre
• la capacité de lire du code et de naviguer dans des bases de code pour en apprécier la structure

Il faudra en reparler.