Corrigez d’abord vos outils

• Lors du suivi d’un bug dans une bibliothèque open source, un problème est survenu : le débogueur ne fonctionnait pas
• Bien que le code ait été exécuté, les points d’arrêt étaient ignorés, ce qui a conduit à chercher le problème par d’autres moyens
• Des tentatives de diagnostic indirectes ont été faites, comme l’ajout de sorties de logs, mais elles n’ont pas apporté les éclairages souhaités
• Finalement, une fois l’erreur de configuration du débogueur corrigée, il a été possible d’observer finement le comportement du programme, ce qui a permis de résoudre le bug
• Cette expérience, où l’on est tellement absorbé par la résolution du problème que l’on néglige le défaut de l’outil lui-même, souligne qu’un développeur doit d’abord corriger ses outils pour résoudre efficacement un problème

---

Problème survenu pendant le diagnostic du bug

• Lors de la recherche d’un bug dans une bibliothèque open source maintenue, le débogueur a commencé à ignorer les points d’arrêt
  • Il était certain que le code exécutait bien cette ligne, mais le programme se terminait sans s’arrêter
  • À force de se concentrer sur la résolution du problème, le souci du débogueur a été ignoré et d’autres approches ont été tentées
• Des modifications du code et des tentatives de diagnostic via l’ajout de logs ont été faites, mais sans obtenir d’informations utiles

Correction du débogueur et résolution du problème

• Il a finalement été décidé de résoudre le problème du débogueur, avec une correction effectuée via un changement de configuration d’une seule ligne
  • Après la correction, il a été possible d’observer en détail le comportement du programme
  • À partir de ces informations, le bug a été résolu avec succès

Prise de conscience et leçon

• La passion de corriger un bug a révélé une situation paradoxale où l’on en vient à négliger le problème de l’outil lui-même
• Il a été constaté que si l’outil ne fonctionne pas correctement, l’efficacité de la résolution du problème diminue
• Ce dont un développeur a besoin, c’est de prendre l’habitude de vérifier et corriger ses outils avant le problème lui-même
• Le texte se conclut sur la formule « Fix your tools », comme un rappel adressé à tous les programmeurs de l’importance des outils

[GN⁺]

Commentaires sur Hacker News

• J’ai 30 ans de carrière, et en ce moment les outils de développement sont vraiment cassés
  J’écris du code sous Linux avec Clio, et les bugs empirent d’année en année
  Maintenant, j’en suis juste à me dire « si ça ne marche pas, tant pis ». La vie est trop courte pour que je passe en plus du temps à corriger le code des autres

• Quand on essaie de corriger le problème, on finit par tomber dans le « yak shaving »
  En voulant régler un petit souci, on se retrouve avec une chaîne sans fin de tâches annexes
  La vidéo associée est visible ici

  • Il n’y a pas de bonne réponse universelle à ce genre de situation
    Parfois, remettre de l’ordre dans ses outils et ses bibliothèques fait exploser la productivité ; d’autres fois, il est plus rapide de foncer en hardcodant
    L’IA aide à affiner les outils, mais en même temps elle élargit le périmètre, si bien qu’on finit par y consacrer autant de temps en gestion d’outillage
    Au fond, c’est un problème de procrastination émotionnelle. On évite de réfléchir à l’architecture d’ensemble en répétant de petites retouches, ou à l’inverse on repousse la conception globale en se contentant de peaufiner les outils de détail
  • C’est dommage que le « yak shaving » soit souvent compris comme une simple perte de temps
    En réalité, c’est aussi une manière de traiter des frictions et inconforts nécessaires
    Mais il faut toujours vérifier si cet inconfort est réellement nécessaire
    Investir 10 à 15 minutes pour automatiser ou raccourcir une tâche répétitive, c’est en fin de compte acheter du temps pour plus tard
  • La vidéo était conforme à ce qu’on pouvait attendre, mais reste drôle
  • Ça me fait aussi penser à XKCD 349
  • Si ce genre de choses arrive, c’est parce que les outils sont tellement laissés à l’abandon qu’ils sont tous cassés
    Au final, la dette technique doit bien être remboursée un jour, donc il faut prendre l’habitude de la payer petit à petit

• L’ingénierie, au fond, c’est une succession d’opérations pour aiguiser la hache
  Comme le dit Kent Beck, j’aime beaucoup l’idée de « rendre le changement facile d’abord, puis faire le changement facile »

  • On m’a confié une tâche d’amélioration de code que je découvrais, mais le code était dans un tel état que j’ai fini par commencer par le refactoring
    C’était bien plus satisfaisant d’améliorer le code que de simplement ajouter une fonctionnalité
  • Cette approche manque encore dans le codage assisté par IA
    L’IA ne trouve pas étrange de répéter plusieurs fois le même code, donc elle ne structure pas et ne réutilise pas bien
  • Aiguiser la hache pendant quatre heures dès le départ peut aussi être inefficace
    En pratique, il est plus réaliste de la réaiguiser au milieu du travail, quand elle s’émousse
  • En programmation, je préfère la « hache » (des outils minimaux comme vim), mais pour abattre un arbre, je me dis aussi qu’une tronçonneuse est nettement meilleure
  • La plupart de mes collègues travaillent comme s’ils coupaient du bois avec un tuyau
    « Là, je suis trop occupé pour aiguiser la hache ! », disent-ils, tout en continuant à travailler de manière inefficace

• J’ai trouvé marquante l’idée que « le désir de corriger un bug peut au contraire masquer le fait qu’il faut d’abord corriger l’outil »
  Kenneth Stanley aborde aussi ce phénomène dans Why Greatness Cannot Be Planned

• C’est un excellent conseil. J’essaie moi aussi de l’appliquer tous les jours
  Mais le conseil suivant — « maintenant, arrête de corriger l’outil et corrige le vrai problème » — est beaucoup plus difficile à respecter

• Moi aussi, je vis souvent ce genre de situation
  Corriger une petite friction fait gagner du temps plus tard, mais il y a le piège de tripoter les outils sans fin
  Le plus difficile, c’est de savoir à quel moment dire « c’est suffisant » et passer à autre chose

• Les outils ont un effet multiplicateur sur l’effort
  Mais il est difficile de trouver l’équilibre entre le « yak shaving » et le travail manuel inutile
  Si l’on prévoit d’utiliser le même outil sur le long terme, il faudrait peut-être pencher davantage vers le yak shaving qu’on ne le pense, car même une amélioration de 1 % produit un effet cumulatif important

• La plus grande leçon, c’est que les outils tout-en-un sont souvent médiocres
  J’ai essayé toutes sortes d’outils no-code comme Make, Airtable et n8n pour une pipeline de contenu, mais au-delà d’une certaine échelle, ils finissent tous par casser
  Au final, appeler directement des API avec des scripts Python était bien plus fiable
  La vraie solution n’était pas de réparer des outils complexes, mais de les remplacer par des outils simples et transparents

  • Je n’ai jamais utilisé d’outil comme n8n, donc je me demande s’il y a des cas où c’est meilleur que Python
  • C’est pour ça que j’aime vraiment Airflow

• Voir directement le flux du code avec un débogueur est extrêmement utile
  C’est beaucoup plus intuitif à comprendre qu’une analyse statique

  • Mais un débogueur n’est pas toujours utile
    À force de modifier les variables ou les points d’arrêt, on perd facilement de vue la nature du problème
    Il faut n’utiliser le débogueur que pour vérifier des hypothèses. Sinon, on tombe dans l’illusion d’avoir avancé

• Si vous aimez ce genre de texte, j’ai envie de plaisanter en disant de ne surtout jamais installer Emacs