Publié le

C'est pas après 10000h passées à coder que tu sauras coder !

Dix mille heures ! Pourquoi cette quantité ? D’après la vulgarisation internet, c’est le temps qu’il faut passer dans n’importe quelle activité pour devenir un·e expert·e. Vraiment ? Je vous le promets, si vous cherchez sur internet, vous trouverez cette information un peu partout.

Mais bien évidemment, c’est une fake-news. Hélas, ce concept a été victime de la progressive désinformation par l’étrange jeu de téléphone arabe qu’est : ✨ la vulgarisation scientifique ✨. Les 10000 heures existent, mais dans un contexte particulier d’un apprentissage supervisé. Voyons ensemble comment ce mythe se déconstruit et pourquoi il est important d’en avoir conscience en développement logiciel.

10000 heures et loi de Brandolini

Qu’est-ce que la règle des 10000 heures ? Elle vient du livre “Outliers: The Story of Success” de Malcom Gladwell. Je n’ai pas lu ce livre, mais l’impact sur la société a été tel qu’il a popularisé le concept en expliquant le succès de plein d’individus à travers la règle des 10000 heures. Très bien, mais d’où vient cette règle ?

Il faut creuser un peu plus loin et rechercher les noms de Anders Ericsson, Ralf Krampe, and Clemens Tesch-Römer. Ces trois chercheurs ont étudié des violonistes à un institut de musique de Berlin et se sont rendus compte que les plus accomplis étaient ceux qui avaient cumulé environ 10000 heures de pratique délibérée de leur instrument en arrivant à l’âge de 20 ans.

Ce nombre ne paraît pas si étonnant. Prenons ma propre pratique délibérée de la guitare : je joue de la guitare depuis 6 ans, j’en pratique délibérément environ 1 h par jour, un rapide calcul mental m’indique que j’ai pratiqué délibérément 2190 heures de guitare. Il me manque encore un ordre de grandeur de pratique délibérée, ce qui correspond à ma sensation : juste assez bon pour jouer une chanson, mais pas assez pour me prendre pour un guitar hero. Pour l’instant, le concept des 10000 heures est un repère utile et un sujet de discussion intéressant, a minima pour tenter de se donner des objectifs.

Mais vous remarquez que j’utilise spécifiquement le terme “pratique délibérée”. C’est le terme utilisé dans la recherche originelle de Ericsson et al. Pour faire simple, la pratique délibérée est celle qui consiste à analyser ses défauts, à tester de corriger ses défauts et à obtenir des feedbacks immédiats sur ses actions.

Prenons l’exemple de ma pratique délibérée de la guitare : si je veux apprendre à jouer sur la guitare la gamme de Do majeur, je vais choisir un exercice qui me permet de la pratiquer. Grâce à mes oreilles, j’entends immédiatement que je fais des fautes. Grâce à un métronome, j’entends immédiatement que je ne suis pas en rythme. Tout cela m’aide à immédiatement corriger mon jeu pour réussir à maîtriser la gamme de Do majeur.

Un exemple de pratique non délibérée de la guitare est le fait de jouer sans direction, jouer ce qui plait, ce qui vient. Jouer des choses telles qu’on le sent n’est pas de la pratique délibérée, car je n’ai pas le feedback nécessaire pour m’améliorer continuellement.

Très bien, nous avons nos hypothèses pour la pratique délibérée d’un domaine d’expertise, notre objectif est assez simple et la méthode est claire. Mais le concept me froissait pour deux raisons :

  1. Est-ce que mon travail n’est pas une pratique délibérée de mon expertise ? Dans cette hypothèse, en supposant travailler 8 h par jour pendant 220 jours par an, je suis à environ 40000 heures de pratique, et pourtant je me sens encore bien loin d’être un expert ! Les calculs ne sont pas bons…
  2. Un podcast 1 m’a fait découvrir que la règle des 10000 heures ne marche pas dans tous les domaines ! Catastrophe ! 🫣 Mais du fait de la loi de Brandolini 2, le concept est répété à tout va et l’effort pour remettre en question la notion des 10 000 h est supérieur à celui qu’il a fallu pour le populariser…

Quelque chose ne va pas avec le concept. Creusons ensemble pour voir comment les 10000 h s’appliquent à notre domaine qu’est le développement informatique.

Kind / Wicked

Je vous invite à regarder le podcast 1 dont je parle au-dessus qui debunk énormément de choses sur la règle des 10000 heures, mais aussi sur plein de choses sur la productivité. Pour résumer la thèse de l’invité, David Epstein :

  • 10000 heures de pratique délibérée fonctionnent dans des domaines d’apprentissages “kind”. C’est-à-dire, que les règles sont claires, ne changent pas, et qu’on peut immédiatement corriger une erreur ou au moins avoir immédiatement une information parfaite si c’est faux ou non. C’est l’exemple de la musique, des échecs, j’oserais dire de la cuisine…
  • Cette règle ne fonctionne pas dans tous les domaines, et précisément dans les domaines d’apprentissages “wicked”. Ce sont ceux qui sont au moins le contraire du domaine précédent : feedback tardif, informations partielles ou erronées, et les règles peuvent changer.

L’exemple que le podcast met en avant est celui d’un médecin qui avait une technique incroyable pour détecter le typhus chez les patients en leur palpant la langue, et il avait un incroyable score de détection de cette maladie. Il se trouvait qu’il était responsable de la transmission de la maladie, et que c’était sa technique qui rendait les patients malades. Un bel exemple de feedback tardif et d’informations erronées…

En connaissance du concept de domaines d’apprentissage kind vs wicked, voici mon assertion :

L’informatique est un domaine d’apprentissage wicked, mais est présenté comme un qui est kind

Il y a deux parties à mon assertion, qui peut se réécrire en : “l’informatique, c’est dur, mais on nous fait croire que c’est facile”. Commençons par la fin.

Absolument pas kind : Le coût du feedback retardé

Est-ce que n’importe qui peut devenir développeur·se ? Je pense que non. Je pense qu’il faut avoir une certaine passion pour les défis complexes, et une certaine forme de patience et de curiosité.

Heureusement ou hélas, il existe de nombreux programmes de reconversion dans l’informatique, qui promettent tout le contraire de ce que je dis. Des formations qui promettent de devenir développeur·se en seulement 1 an, 6 mois, 3 mois… Bientôt on va voir des écoles d’informatique qui forment en 1 heure… Comme si finalement, l’informatique n’était pas si complexe, et qu’il n’y avait pas besoin d’autant de patience que cela pour devenir un·e professionnel·le du développement logiciel. Comment on est-on arrivé là ?

Il y a deux raisons : la première, c’est que malgré la crise actuelle qui touche les métiers du développement, cela reste un secteur en très forte demande, et de nombreux talents existent dans la nature et parfois ne sont même pas au courant qu’iels ont une très forte appétence dans ce domaine.

La deuxième, c’est que c’est bizarrement très facile de donner l’impression d’apprendre l’informatique. Que vous soyez doué en flexbox froggy, que vous ayez réalisé tous les exercices de CodinGame, ou que vous ayez créé 40 sites portfolio 3, vous avez l’impression d’apprendre et d’avoir un feedback immédiat sur ce que vous faites.

Alors oui, apprendre à faire des pages web ou des services, ou créer des formulaires ou déployer sur Vercel, ce sont des actions qui démontrent votre expertise et vous aide à obtenir la confiance, le feedback immédiat, pour vous professionnaliser. Mais j’ai une mauvaise nouvelle :

Le vrai développement logiciel ne donne pas de feedback immédiat.

Je vous donne un exemple dramatique : La machine Therac-25.

Je vous paraphrase l’article Wikipédia : c’est une machine de radiothérapie qui avait des bugs qui donnait des doses mortelles de radiation, et 5 patients au moins en sont morts. Tout est dans l’article, et même les causes et les analyses.

Le premier prototype a été commencé en 1976, la machine commercialisée en 1982, et le premier incident a eu lieu en 1985. Autrement dit, il aura fallu 10 ans pour avoir un premier “feedback” que le code pouvait tuer ses patients. Quelles horribles conditions de développement…

Le feedback retardé est déjà théorisé en développement logiciel : on parle de dette technique, de coût de délai. Il est parfois difficile de négocier une diminution de la dette technique, car sa mesure est lente à faire et la rentabilité des investissements de la diminution de la dette technique est aussi un feedback retardé.

Les règles du développement logiciel sont injustes

Durant nos études d’informatique, on nous apprend des règles bien pratiques du développement logiciel :

  • Il faut avoir un code propre, par exemple en évitant la duplication de code ♻️
  • Il faut écrire des tests unitaires qui couvrent 100% des lignes écrites 📝
  • On nous parle de patterns de programmation comme la programmation objet 🔫

Une fois au travail, les règles changent totalement. Mes plus grandes surprises à moi :

  • Ce n’est pas une mauvaise chose d’avoir du code dupliqué s’il correspond à des fonctionnalités différentes 4. 🫣
  • Les tests unitaires n’apportent pas systématiquement de valeur à un projet et il est préféré de tester de bout-en-bout sa solution 5. 🤑
  • La programmation objet n’a pas de succès en développement web 6… 😮‍💨

Parfois je me demande si je ne me suis pas endormi durant mes études, car j’ai vraiment senti un décalage entre ce qu’on m’a appris et ce qui apportait de la valeur. S’il existe des règles dans l’informatique, pour moi il n’y en a qu’une : est-ce que ce que vous faites apporte de la valeur ?

Buzz l'éclair disant \

Avons-nous une information parfaite ?

Celui-là est plus conceptuel. J’aimerais vous raconter une histoire vraie que j’ai rencontré au travail chez un de mes clients.

Une fonctionnalité important touchant l’encaissement de chèques allait être mise à jour. Le client avait demandé à ses utilisateurs de ne plus utiliser l’ancien service et d’attendre la sortie de la nouvelle fonctionnalité pour faire encaisser leurs chèques. Pourquoi pas…

La nouvelle fonctionnalité sort durant le weekend, les utilisateurs commencent à l’utiliser dès le lundi. Oups, un premier feedback décalé.

Le lundi matin, autour de 10 000 agents font encaisser des centaines de chèques dès le matin. Bien évidemment, tout pète. Cellule de crise, la totale. La question tombe sur moi (qui était chargé de la correction de bugs sur la partie frontend) : Pourquoi les agents n’ont pas reçu de message d’erreur d’encaissement de chèque ?

La cause était fascinante, et je suis choqué de voir qu’aucun post-mortem n’a été fait pour ce problème. En gros. La feature se basait sur une obscure technologie legacy qui avait été dimensionnée pour un usage quotidien. Mais rappelons-nous, on a demandé aux utilisateurs de ne plus utiliser l’ancien service et d’attendre. Ils auront attendu presque 1 mois… Le dimensionnement n’était pas calé pour une utilisation environ 1000 fois plus intensive que prévu. Oups, la règle a changé.

Comme ce service était en PLS, notre frontend était bien préparé pour recevoir un message d’erreur et l’afficher. Et le service backend émettait bien des erreurs durant les tests si jamais l’encaissement entrait en erreur… Mmm, quelque chose n’est pas bon. L’enquête continue.

En tant qu’expert de correction de bugs, j’analyse avec Dynatrace le comportement des utilisateurs. Je remarque deux choses : l’écran de validation d’un chèque est bloquant, c’est-à-dire qu’une fois le chèque envoyé, il n’est pas possible de continuer à utiliser l’application tant que le service ne répond pas positivement ou négativement. C’est original, mais la raison est claire : c’est pour être sûr que l’utilisateur ne part pas tant qu’il n’a pas encaissé son chèque. Je note cela quelque part et je continue l’analyse.

Autre constatation : le temps de réponse du service est très lent : 30 secondes pour entrer en timeout (c’est en gros le temps avant qu’on dise que le service ne répondra jamais). Et je vois sur dynatrace de nombreux rage clicks. C’est quand la personne clique incessamment sur son application en espérant obtenir un comportement différent. C’est alors que je capte :

On pensait qu’il y avait une erreur côté frontend car les utilisateurs ne recevait pas de message d’erreur. En fait, ils finissaient bien par le recevoir. L’analyse a posteriori a montré que le service backend était totalement dans les choux, dans un deadlock (l’impossibilité d’ajouter des données du fait d’un trop grand nombre d’insertions) de sa base de données. Il émettait un message d’erreur qui était bien capté par le frontend et bien affiché.

Mais le souci, c’est nos utilisateurs n’en avaient rien à faire : ils étaient très pressés de pouvoir faire encaisser leur centaine de chèques, et comme l’application était lente, ils avaient tendance à ouvrir plusieurs onglets, à fermer et refermer les fenêtres pour réussir à faire encaisser le plus vite possible tous leurs chèques. Le message n’apparaissant qu’au bout du timeout de 30 secondes, presque aucun n’a vu le problème. Aïe aïe aïe… Dans mon rapport de bug, la cause était sans équivoque : le frontend n’a pas été bien conçu pour gérer l’impatience d’un utilisateur pressé ; le backend n’était pas dimensionné pour faire ce qu’il devait faire. Quelle aventure.

Je raconte cet exemple, car il représente pour moi l’épitomé d’une situation avec information très imparfaite : pour comprendre le bug, il fallait comprendre le contexte des utilisateurs. J’aurais bien aimé être au courant que cette feature allait sortir et provoquer des usages massifs de ce service ! J’aurais eu moins de soucis pour analyser.

Donc l’informatique est un domaine à feedback retardé, avec des règles changeantes et des informations partielles. Génial. Pourquoi nous posions-nous cette question ? Parce que nous nous demandions s’il suffisait de pratiquer l’informatique pendant 10000 heures pour devenir expert. Comme l’informatique n’est pas un domaine d’apprentissage “kind”, nous arrivons à la conclusion que non.

Peut-on rendre l’informatique plus saine à apprendre ?

Oui ! Et nous le devons. Nous devons arrêter d’envoyer en première ligne des personnes qui viennent d’apprendre l’informatique comme s’il s’agissait d’un chemin tranquille. C’est un univers dur. Être développeur·se, aujourd’hui, ce n’est pas seulement être expert de son domaine, c’est aussi être curieux·se et observateur·trice du monde dans lequel nous vivons. Nous avons la responsabilité de construire un monde meilleur, et nous ne pouvons y arriver qu’en concevant que l’informatique est un domaine d’apprentissage aux règles injustes, aux feedbacks tardifs et avec des informations erronées ou partielles. Comment mieux naviguer dans cet environnement ?

Il se trouve que durant les précédentes années, plein de méthodologies et de techniques de développement logiciel ont émergé pour rendre l’informatique un domaine d’apprentissage “kind”. En fait, il suffirait d’agir sur un de ces trois leviers :

  • Réduire le temps de feedback
  • Fixer les règles du jeu, que l’on peut traduire en comprendre le besoin utilisateur
  • Améliorer l’information diffusée

Toute équipe de développement se doit d’agir, par une approche holistique, sur ces trois leviers pour réussir à apprendre et à mieux développer ses logiciels.

Que ce soit par votre organisation du travail, par exemple sous agilité scrum, que ce soit par votre architecture, en ayant la possibilité de facilement modifier seulement une partie de votre code sans régressions par rapport aux besoins changeants, ou que ce soit par votre façon de communiquer pour améliorer la diffusion de l’information, nous avons plein de moyens pour rendre l’informatique plus “kind” à apprendre, le métier plus simple.

Pour nous toutes et tous étant dans des équipes de développement, nous devons nous concentrer sur l’apport de valeur. La technique est nécessaire, mais elle n’est pas suffisante pour réussir un projet. C’est d’autant plus vrai qu’aujourd’hui, avec le progrès de l’IA, je pense sincèrement que la technique du développement logicielle va radicalement changer. Peut-être les règles du jeu de l’informatique vont changer ? Mais l’apport de valeur, lui, reste une constante de la vie.


Je m’appelle Nirina Rabeson, je suis développeur frontend qui parle de la place de l’humanité dans la tech.

J’ai une newsletter ! C’est bizarrement plus compliqué que ce que j’imaginais à mettre en place, donc tu peux m’envoyer un mail à pour t’y ajouter : hello@nirinarabeson.fr

En attendant la newsletter, j’ai un flux RSS


Footnotes

  1. The No.1 Productivity Expert: 10,000 Hours Is A Lie! This Morning Habit Is Ruining Your Day! 2

  2. La loi dite de Brandolini ou le principe d’asymétrie des baratins est l’aphorisme selon lequel « la quantité d’énergie nécessaire pour réfuter des sottises […] est supérieure d’un ordre de grandeur à celle nécessaire pour les produire ».

  3. Je suis fier de mon propre portfolio de mes projets personnels du coup je le partage : Mes projets !. D’ailleurs, je travaille en exclusivité sur un générateur de formulaires vuejs utilisant de l’IA pour convertir des schémas zod… stay tuned…

  4. Parlons de domain-driven-design : https://martinfowler.com/bliki/BoundedContext.html

  5. Parlons de stratégie de test par trophée : https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications

  6. Les frameworks frontend ont globalement tous laissé tomber la notion d’objet pour préférer l’utilisation de fonctions, et cela est très amplifié avec les concepts de composables et de hooks.