La joie et la puissance de la compréhension

• Comprendre un logiciel en profondeur permet de ne pas se laisser entraîner par les outils et de garder le contrôle et la maîtrise du système dont on a la responsabilité
• La recherche et les LLM donnent des réponses rapides, mais l’habitude de copier des solutions qu’on ne sait pas expliquer peut affaiblir la capacité à les corriger ainsi que les compétences clés
• Pour des scripts ponctuels ou des interfaces internes à faible risque, générer ou copier-coller peut être rationnel, mais le code destiné à durer doit être écrit avec des technologies que l’on connaît en profondeur
• Si l’on mesure la productivité uniquement par l’output, comme le nombre de lignes de code ou de PR, on la fausse facilement ; les outcomes comme des releases stables, la simplification, l’automatisation ou les tests sont plus proches de la valeur à long terme
• Le logiciel moderne s’est complexifié, du runtime au réseau, à la sécurité, aux bases de données et à l’IA, mais maîtriser les principes fondamentaux permet de comprendre plus vite les nouveaux outils et les nouvelles approches

---

Le contrôle et le plaisir qu’apporte la compréhension

• Une compréhension approfondie est une condition concrète pour corriger et faire évoluer du code et des systèmes
• Il est difficile de modifier ce que l’on ne comprend pas, et l’on finit par perdre en contrôle et en responsabilité sur le code dont on a la charge
• Comprendre permet non seulement de rester maître des outils, mais apporte aussi une satisfaction psychologique
• Il est naturel que les comportements qui nous donnent davantage de contrôle sur notre environnement soient associés à des émotions positives

La paresse humaine et la dépendance aux LLM

• L’être humain a tendance à réduire sa dépense d’énergie et à maximiser la récompense par rapport à l’effort investi
• Cette paresse peut motiver l’automatisation des tâches ennuyeuses et coûteuses, mais devenir un point faible quand il s’agit d’apprendre et de se perfectionner
• Grâce à Internet et aux LLM, il est facile d’obtenir la réponse à des problèmes similaires dans la forme souhaitée, ce qui pousse à court-circuiter le processus de compréhension
• Au lieu d’apprendre SQL directement, on peut décrire les tables et les données souhaitées à un LLM puis copier simplement le résultat : c’est plus facile sur le moment, mais cela ne construit pas une vraie maîtrise
• Même si un LLM génère du SQL plus vite, les capacités de lecture et de compréhension développées autrefois par la répétition régressent si on cesse de les exercer
• Les LLM et les moteurs de recherche sont, au mieux, des amplificateurs de capacité (force multipliers), mais ils exigent d’abord de solides bases
• Il est difficile de maintenir des techniques et connaissances essentielles uniquement avec la recherche, les prompts et la validation manuelle ; il faut participer directement à la construction et à la création
• Il faut régulièrement lutter contre cette tendance à la paresse : lire la documentation et le code source, comprendre les raisons d’une solution et les compromis d’un outil, et concevoir soi-même des solutions et des algorithmes

Équilibrer productivité à court terme et compréhension à long terme

• Il n’est pas nécessaire de tout comprendre parfaitement dans chaque ligne de code ou chaque solution ; le niveau d’exigence peut varier selon le contexte
• Pour des scripts ponctuels de faible importance et de faible risque, copier ou générer du code peut convenir
• On peut accepter la même approche pour une UI ou une page interne utilisée par deux ou trois personnes
• Mais le code que l’on devra posséder, maintenir et faire évoluer pendant des mois ou des années doit être écrit avec des langages et des technologies que l’on connaît en profondeur
  • Il faut pouvoir comprendre, ou tendre à comprendre, chaque ligne, chaque mot, chaque caractère et chaque option de configuration
  • Il faut optimiser la compréhension, la maintenabilité et la productivité à long terme plutôt que maximiser immédiatement la quantité de livrables
• Pour un MVP ou une fonctionnalité expérimentale dans un produit existant, dont le succès est encore incertain, on peut légèrement abaisser les exigences de qualité et de compréhension
• Ce type de choix ressemble à une dette cognitive
  • On peut aller plus vite pour le moment
  • Mais si le produit ou la fonctionnalité fonctionne, ou s’il faut le corriger et le faire évoluer, il faudra payer davantage plus tard
• Malgré tout, il faut au minimum comprendre et valider suffisamment pour pouvoir affirmer avec confiance : « ça fonctionne »
• Dans certains cas, une stratégie raisonnable consiste à générer d’abord, valider ensuite, puis réécrire depuis zéro

L’effet cumulatif de la stack technique et de la maîtrise

• Pour un langage, une bibliothèque ou un outil que l’on utilise rarement, il n’est pas nécessaire d’investir beaucoup de temps dans un apprentissage approfondi et dans la maîtrise
• Si l’on sait valider le résultat, copier ou générer à partir d’une compréhension partielle peut parfois être acceptable
• Mais en sautant les étapes d’apprentissage et d’effort, on réduit soi-même ses chances de devenir compétent et productif avec cette technologie
• Dans la stack technique que l’on utilise régulièrement, la maîtrise peut rapporter au centuple, voire au millième
• Les connaissances et les compétences ont un effet cumulatif
  • Plus on en sait, plus on peut construire vite par soi-même
  • On acquiert aussi de nouvelles connaissances et compétences de plus en plus rapidement
  • Plus ses capacités augmentent, plus il devient possible d’imaginer de nouvelles solutions et de nouvelles idées

Une productivité orientée vers l’outcome plutôt que l’output

• Il existe globalement deux manières de comprendre et de mesurer la productivité : une approche centrée sur l’output et une autre sur l’outcome
• L’output est facile à mesurer et simple à compter
  • Le nombre de lignes de code produites
  • Le nombre de PR ouvertes et fusionnées
  • Le nombre de fonctionnalités implémentées
  • Le nombre de bugs trouvés et corrigés
  • Le nombre de tâches terminées
• Les indicateurs centrés sur l’output se manipulent facilement
  • On peut écrire du code verbeux
  • On peut multiplier les petites PR
  • On peut découper artificiellement le travail
  • On peut ajouter des fonctionnalités inutiles
• Même si les chiffres augmentent, rien ne garantit que l’on va dans la bonne direction
  • Beaucoup de PR ne veut pas forcément dire mieux
  • Une base de code plus grosse n’est pas toujours souhaitable
  • Il peut être préférable de supprimer des fonctionnalités inutilisées plutôt que d’en ajouter
• Des exemples orientés outcome sont plus directement liés à la valeur à long terme
  • Un nouveau processus de CI/CD rend les mises en production plus stables
  • Le refactoring et la simplification facilitent la maintenance et les changements futurs
  • La refonte d’une solution d’intégration accélère l’ajout de nouveaux partenaires tout en économisant des ressources de calcul
  • Davantage de tests permettent de détecter les bugs en amont et d’éviter les régressions
  • L’ajout de métriques et d’alertes aide à repérer de manière proactive des problèmes potentiels et des bugs
  • L’automatisation des tâches manuelles fastidieuses fait gagner du temps et réduit le risque d’erreurs critiques
• La productivité à long terme et la compréhension s’alignent mieux avec des métriques centrées sur l’outcome, et davantage d’output ne signifie pas toujours de meilleurs résultats

Des logiciels toujours plus complexes et les principes fondamentaux

• Le théorème fondamental du génie logiciel se résume souvent ainsi : « N’importe quel problème en informatique peut être résolu par un niveau d’indirection supplémentaire, sauf le problème d’un trop grand nombre de niveaux d’indirection »
• Le développement logiciel moderne est très complexe à cause de ses nombreuses couches et composantes
  • Runtime et plateformes : navigateur, serveur, cloud, mobile, desktop, embarqué
  • Réseau : HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, protocoles des bases de données et des message brokers
  • Sécurité, authentification, autorisation
  • Systèmes d’exploitation
  • Virtualisation, conteneurisation, orchestrations de type Kubernetes
  • Bases de données : SQL, NoSQL, locales, distantes, distribuées
  • Langages de programmation de haut niveau et pipelines de compilateurs, interpréteurs et transpileurs
  • Bibliothèques, frameworks, gestionnaires de paquets
  • API et services externes
  • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
  • LLM et IA
• Il existe toutefois des raisons de penser que cette complexité reste gérable
  • Beaucoup de systèmes sont surconçus et peuvent être considérablement simplifiés
  • À une période donnée, il suffit généralement de maîtriser en profondeur une petite partie du paysage logiciel
  • Pour le reste, un niveau de simple familiarité peut suffire
  • Comprendre les motifs généraux et les principes derrière les outils donne un effet de levier pour apprendre de nouveaux outils, approches et techniques

La portée et les effets des principes fondamentaux

• Les principes fondamentaux sont les règles, contraintes et mécanismes de base, relativement stables, qui se trouvent sous les outils, bibliothèques, frameworks, protocoles et composants utilisés dans le développement logiciel
• Leur champ couvre plusieurs domaines essentiels
  • Architecture des ordinateurs et matériel : structure du CPU, exécution des instructions, hiérarchie mémoire, registres, cache, stockage
  • Code machine, assembleur et langages de haut niveau : pourquoi les assembleurs, compilateurs et interpréteurs sont nécessaires, et quels sont les compromis selon les types de langage
  • Systèmes d’exploitation : processus, threads, ordonnancement, verrous, synchronisation, mémoire virtuelle, systèmes de fichiers, IPC, appels système, I/O
  • Algorithmes, structures de données, analyse de complexité
  • Réseau : communication entre ordinateurs, fiabilité, débit, latence, architecture en couches
  • Bases de données et systèmes de données : ACID, transactions, niveaux d’isolation, index, modes de stockage, relations, modélisation des données
  • Conception et architecture logicielle : modularité, gestion des dépendances et des responsabilités, masquage de l’information, encapsulation, couches, client-serveur, événements, couplage et cohésion
  • État et flux de données : identité, source unique de vérité, résolution des conflits, cache et mémoïsation, invalidation d’état, machines à états, cohérence et synchronisation
  • Systèmes distribués : théorème CAP, réplication, latence, partitions, consensus, service discovery, cohérence éventuelle
  • Concurrence et parallélisme : verrous, synchronisation, possibilités de parallélisation, conditions de course, interblocages
• Il n’est ni nécessaire ni forcément possible de maîtriser tous ces domaines, mais il faut viser une connaissance de base dans chacun et l’excellence dans quelques-uns choisis
• En se concentrant sur les principes fondamentaux, on développe avec le temps une méta-compétence : une intuition universelle
• Une compréhension approfondie du fonctionnement de l’informatique et des ordinateurs, seuls ou en cluster, permet de moins subir les détails mouvants des outils et frameworks
• À ce niveau, apprendre un nouvel outil à la mode devient aussi beaucoup plus facile

La joie de comprendre et sa portée

• Comme le disait Leonardo da Vinci, « la plus noble des joies est la joie de comprendre »
• Dans le développement logiciel, la compréhension n’apporte pas seulement du plaisir, mais aussi une influence concrète et une forme de puissance
• Le champ du génie logiciel est immense, mais se concentrer sur les principes fondamentaux élargit la part que l’on peut réellement maîtriser
• Continuer à repousser ses limites cognitives mène régulièrement à davantage de joie et à une influence croissante

[GN⁺]

Avis sur Lobste.rs

• J’ai vraiment aimé le ton général de ce billet de blog
  En ce moment, je vois beaucoup trop souvent des posts du genre « j’ai créé un outil sans même savoir ce qui se passe à l’intérieur », et je suis fatigué de cette ambiance qui traite ça comme quelque chose dont on peut être fier

  • Oui. Une compréhension profonde crée un véritable avantage et mène à de nouvelles idées et intuitions
    Et le fait que le processus lui-même soit très agréable compte aussi énormément

• C’était un article intéressant, et je pense que cette tendance à pousser les gens à produire des résultats qu’ils ne comprennent pas est en partie intentionnelle
  Du point de vue des labos IA, il y a clairement une logique économique. Les gens doivent dépendre de leurs produits pour qu’ils puissent commencer à justifier leur valorisation, et affaiblir les capacités des utilisateurs en fait partie
  J’ai justement écrit aujourd’hui un billet similaire, qui partage la même idée centrale sur le plaisir d’apprendre réellement quelque chose et d’en acquérir la maîtrise : https://hgrsd.nl/blog/simplicity-agency-and-mastery/

  • Merci d’avoir partagé l’article. Le point sur l’autonomie et l’effet boule de neige m’a particulièrement plu
    Il ne faut jamais abandonner son autonomie, et plus on sait et plus on est capable de faire, plus on devient capable d’en savoir et d’en faire davantage. C’est une très belle boucle de rétroaction positive

• J’étais content que cet article n’ait pas reçu le terrifiant tag vibecoding. En réalité, on tient ce genre de discours depuis des décennies, en plus court et souvent sur un ton plus grincheux
  Le logiciel est horriblement complexe, donc il existe beaucoup de raccourcis cognitifs, et à un certain point ils sont même nécessaires pour survivre. Mais les humains ont tendance à devenir paresseux plus facilement qu’à faire preuve de prudence quand il le faudrait. Les ordinateurs se prêtent bien à une modularisation stricte, les humains beaucoup moins
  J’ai apprécié que cet article ne présente pas la compréhension comme un simple « devoir », mais insiste sur le fait qu’il est amusant de comprendre comment quelque chose fonctionne. Il y a peut-être des gens qui n’aiment pas comprendre le monde, mais c’est un aspect tellement essentiel de ma personnalité que cela me paraît presque purement théorique. Si ce plaisir n’existe pas, il faut peut-être reconsidérer les choses avant de se lancer dans une carrière dans le logiciel

  • Je vois le tag vibecoding sur cet article
    En ce moment, presque tous les articles ont un tag vibecoding, donc il vaudrait peut-être mieux inverser l’idée et introduire un tag non-vibecoding. On l’utiliserait uniquement pour ce qui n’est pas du vibe coding ou pour les articles sur les avantages du vibe coding, et on laisserait tout le reste tel quel. Malheureusement, ça ressemble à la nouvelle norme
    C’est un bon article qui est aussi « sur la même vibe » que mes sentiments

• J’aime vraiment apprendre, et comme le texte parle de ces situations où l’on « génère quelque chose qu’on ne comprend que partiellement, puis où l’on doit passer plus de temps à le comprendre », personnellement ce genre de dette cognitive ne me déplaît pas
  Si c’est dans un domaine qui m’intéresse, je suis prêt à prendre le temps de rembourser cette dette et d’acquérir la compréhension. Au final, cela ressemble juste à une autre voie pour parvenir à la même compréhension
  Cela me fait aussi penser au concept de lean startup. Lorsqu’on a quelque chose de concret à regarder, on peut commencer en disséquant un objet tangible au lieu de deviner ce qui compte face à un écran vide. Ne pas savoir par où commencer est pire, et l’IA peut aider à démarrer rapidement
  Ce que j’arrive encore mal à formuler, c’est la manière dont des juniors peu expérimentés développent l’intuition nécessaire pour repérer les signaux d’alerte et les contester. Ma manière d’utiliser l’IA est très itérative, et je la traite comme une sorte de dialogue socratique pour m’améliorer. C’est très différent d’un univers de vibe coding en one-shot tel qu’il est possible avec les outils actuels

  • À propos du point « comment des juniors peu expérimentés développent l’intuition nécessaire pour repérer les signaux d’alerte et les contester », j’ai des amis proches et des membres de ma famille qui viennent tout juste d’entrer dans le secteur depuis la fin de l’année dernière
    En pratique, je ne pense pas que ce soit très différent d’avant. Des personnes plus seniors leur donneront des conseils et leur répondront, et dans la plupart des entreprises tech il y a aussi de la revue par les pairs. Donc les juniors ne sont pas complètement seuls. Ils ont même largement le temps de se tromper et de s’adapter

• J’ai aimé qu’il énumère pas mal de sujets fondamentaux
  Le lecteur peut facilement imaginer qu’il s’agit d’un procédé rhétorique comme le Gish gallop ou la parading of horribles, mais en réalité je pense qu’il existe des dizaines de théories fondamentales qui se croisent à chaque instant de notre vie
  Les ordinateurs ne sont pas programmés à partir d’une théorie unifiée unique, mais ressemblent plutôt à un diagramme d’inclusion d’ensembles qui se chevauchent, formé par l’assemblage de nombreuses petites théories

• J’ai lu l’article avec beaucoup de plaisir et d’attention, et je l’ai aussi partagé avec quelques amis
  Comme il devient de plus en plus difficile de ralentir, j’ai aussi écrit https://writing.tidefield.dev/hello-world-again/#honing-my-focus pour m’engager publiquement à me consacrer à l’apprentissage des fondamentaux pour la nouvelle année
  J’étais heureux de voir cette même orientation : « après 2026, j’étudierai des choses fondamentales qui ne seront pas vite emportées par les modes… »