Linus Torvalds illustre ici ce qu’il considère comme du « garbage code » : des abstractions inutiles qui alourdissent la compréhension du code, comme une fonction make_u32_from_two_u16(a,b) qui masque la simplicité et la clarté de l’opération (a << 16) + b. Son argument central : le bon code optimise la charge cognitive. Chaque abstraction ou fonction helper impose un coût en termes de contexte (pour les humains comme pour les LLMs), car elle nécessite de « sauter » mentalement vers une autre partie du code, ce qui consomme de l’énergie et augmente le risque d’erreurs. Parfois, la duplication ou l’écriture explicite est préférable à une abstraction prématurée, surtout si celle-ci ne clarifie pas le code ou n’est pas réutilisée massivement. Torvalds rappelle aussi que le coût de la duplication a diminué avec les outils modernes de refactoring. Enfin, l’article souligne l’importance de la bienveillance dans les revues de code, même si le fond du message de Linus reste pertinent : privilégier la lisibilité et la localité du code.
L’article propose un exercice simple pour identifier et réduire la charge mentale au travail, souvent source d’angoisse et de fatigue invisible. L’idée est de noter pendant une semaine toutes les petites contrariétés du quotidien (tâches répétitives, interruptions, demandes hors périmètre) sans les juger, afin de dresser un « relevé brut » de ce qui grignote temps et énergie. À l’issue de cette observation, trois questions clés permettent d’agir : automatiser les tâches répétitives, déléguer ce qui ne relève pas de son expertise, ou supprimer ce qui n’est plus nécessaire. L’objectif n’est pas une solution miracle, mais une prise de recul concrète pour reprendre le contrôle et alléger son quotidien, en se concentrant sur l’essentiel plutôt que sur l’accumulation de détails épuisants.
Un outil utile pour ceux qui se sentent débordés sans raison apparente !
L'auteur décrit une méthodologie (décrite dans le livre "Team topologies") pour répartir les équipes de développement en fonction de la complexité des domaines (au sens DDD), des relations entre domaines, etc. de manière à réguler la charge cognitive.
Tout est dans le titre