- À force de répéter de petites automatisations, on finit par atteindre un seuil cognitif où tous les outils et systèmes apparaissent comme des objets à réparer
- Plus les compétences techniques s’accumulent, plus on dépasse la simple perception des problèmes pour porter le poids émotionnel d’une responsabilité
- Le désir de réparer dépasse parfois le simple gain de productivité et devient un moyen de réguler ses émotions, au point de se retrouver soi-même piégé dans le système qu’on a créé
- Avec le temps, les systèmes finissent inévitablement par se dégrader, et l’illusion d’une solution parfaite n’existe pas
- Au final, la vraie compétence nécessaire n’est pas de tout réparer, mais d’avoir la sérénité mentale de supporter que certaines choses restent en l’état
Au départ, une petite automatisation
- Tout commence avec de petits gains de productivité, comme un script Python pour renommer des fichiers ou des raccourcis pour les commandes
git - Une fois qu’on a corrigé soi-même les irritants d’un système, tout dans le monde commence à ressembler à quelque chose qu’on pourrait améliorer
- À un certain moment, on passe du simple « je peux le faire » à une compulsion morale : « je dois le faire »
Le poids des compétences techniques
- Avant de programmer, on pouvait ignorer un logiciel inconfortable ; maintenant, les problèmes sautent aux yeux
- Le code bancal ou les configurations hardcodées écrits par d’autres développeurs peuvent sonner comme un reproche
- On en vient à percevoir tous les systèmes et logiciels comme une liste de TODO à corriger
Une vie de refactor sans fin
- On se laisse happer par le développement de ses propres outils, en se disant à chaque fois : « ça, je peux le faire mieux moi-même »
- Les répertoires de code désordonnés, les innombrables tentatives et abandons, les restructurations sans fin peuvent devenir une forme de travail auto-contraignant
- Comme dans la métaphore de Kafka, « construire une cage et attendre l’oiseau », on peut se perdre dans la fabrication d’outils sans but réel
Le logiciel se dégrade
- Même un script qui semblait parfait finit un jour par devenir inutile à cause de changements extérieurs
- modification de la mise en page d’un site web, changement de version d’un package, erreur de dépendance, etc.
- Quand un problème survient, on ne ressent pas seulement une gêne, mais aussi de la culpabilité
- On se retrouve finalement face à la réalité d’une maintenance continue
L’illusion de l’automatisation
- On nourrit souvent le faux espoir que « si je le configure une fois, je n’aurai plus jamais à y toucher »
- On imagine la programmation comme une victoire sur les problèmes, alors qu’il ne s’agit que d’une guerre sans fin
- Il n’existe pas d’état final achevé : on ne fait que creuser des tranchées qui seront toujours inondées
Quand coder devient un outil de régulation émotionnelle
- Le fait de construire des outils est parfois une réaction psychologique pour reprendre le contrôle sur le chaos de la vie
- Plus le système devient complexe, plus on a paradoxalement l’impression d’être soi-même en ordre
- Pour éviter une vie compliquée, on tente une nouvelle app ou un refactoring, et on y trouve une forme d’auto-apaisement
Le burn-out sans avertissement
- Le burn-out ne vient pas seulement du surmenage, mais aussi d’un excès de sens des responsabilités
- Le reproche qu’on se fait à soi-même — « pourquoi je ne corrige pas quelque chose que je suis capable de corriger ? » — aggrave le stress
- Ce sentiment de responsabilité technique sans fin devient un poids autodestructeur
Apprendre l’art de lâcher prise
- Il n’est pas nécessaire de résoudre tous les problèmes
- Parfois, savoir qu’on n’a pas besoin de réparer est une forme de contrôle encore plus grande
- Reconnaître les défauts et continuer à utiliser les choses telles quelles peut aussi être un choix conscient
La vraie compétence, c’est la clarté émotionnelle
- Plus que la capacité de réparer, c’est la capacité intérieure à ne pas réparer qui compte vraiment
- Savoir quand s’arrêter, et distinguer les projets qui servent surtout à se rassurer soi-même
- Il faut sortir de l’obsession de tout corriger et apprendre à trouver du confort dans l’imperfection
Au fond, la compétence la plus difficile en programmation,
c’est d’apprendre « à laisser tel quel ce qui est cassé »
21 commentaires
Toute chose a un but. Si ce but a été atteint, il n’est plus nécessaire de la corriger. Mais si ce but n’a pas été atteint, il faut la corriger.
Commencer par identifier clairement l’objectif du projet semble être la première étape.
On se sent tout de suite plus à l’aise quand on réalise qu’il existe aussi des entreprises valant des centaines de milliards de wons rien qu’en regroupant et en mettant de l’ordre dans les API bancaires et de paiement complètement en vrac, haha
Coupang..
Si voir qu’un système construit avec VB 6.0 et COM + OLE + ActiveX fonctionne encore très bien vous horrifie au point de vous donner envie de tout réécrire, alors vous êtes condamné à souffrir.
Au final, la compétence la plus difficile en programmation,
C’est d’apprendre à « laisser tel quel ce qui est cassé ».
Je suis d’accord. Comme je suis du genre à me lancer dans tout, je finis toujours par en baver...
Une automatisation bricolée à la va-vite par un simple programmeur est forcément vouée à casser.
Bon contenu
Le point de la surcharge jusqu’au burn-out
: quand, après avoir péniblement automatisé son travail, c’est le collègue d’à côté qui en profite, tandis que soi-même on se retrouve affecté à l’automatisation d’autres tâches ;
Je fais partie de ceux qui ont passé 2 jours à automatiser une tâche qui prend 15 minutes, et qu’on traite ensuite de glandeurs payés à rien faire.
Le sens excessif des responsabilités est presque une maladie professionnelle chez les programmeurs, donc il faut le résoudre au niveau du système.
C'est à l'équipe Quality Assurance d'assurer cela.
La QA peut-elle freiner le sens excessif des responsabilités des développeurs ? J’ai du mal à bien comprendre.
À force de reprocher au développeur en cherchant à savoir s’il est fautif, avec des « c’est toi qui as mal codé »,
le développeur finit écrasé par le sens des responsabilités et en vient à éviter toute nouvelle tentative.
Au final, il ne reste plus qu’à écrire un code sûr, mais sans progrès.
C’est précisément ce que signifie le fait que la QA doit assurer.
Pour faire du code qui fasse avancer les choses, il faut forcément accepter une certaine part de risque,
et c’est à la QA de le valider et d’en assumer la responsabilité.
On peut donc lire cet article comme ça ? Pour ma part, s’il fallait vraiment le qualifier, j’avais plutôt l’impression que c’était un texte qui critiquait le yak shaving.
Comme l’a dit roxie, le texte parle bien de yak shaving,
mais à la lumière de mon expérience personnelle, j’en ai fait une histoire un peu différente du contenu initial.
Ne pourrait-on pas aussi l’expliquer par le phénomène NIH (not invented here) ? Je pense qu’il ne faut pas oublier que la maintenance représente en soi un coût fixe et que ce coût inclut aussi l’effort humain.
Pour pouvoir continuer à faire ça longtemps, il faut sans doute aussi apprendre, de temps en temps, à poser le poids des responsabilités et des émotions avant de tomber dans le piège d’un besoin de compensation nourri par un sens excessif des responsabilités.
C’est aussi quelque chose que j’ai du mal à bien gérer, haha… mais c’est un bon texte.
Je pense que c’est un très bon point. Le sens des responsabilités, c’est littéralement le fait de se sentir responsable, donc par nature cela n’exige pas de contrepartie. Mais avec le temps, alors que le corps et l’esprit s’épuisent, ce sens des responsabilités, lui, ne disparaît pas facilement, et pour combler cet écart, on commence, sans même s’en rendre compte, à attendre une contrepartie (même si, ainsi reliés, les deux ne devraient pas l’être).
Eh bien, un compromis un peu meilleur que « laisser ce qui est cassé tel quel », ce serait sans doute : « n’y touche pas tant que ce n’est pas cassé » :)
Avis sur Hacker News
Partage une citation apprise en faisant du théâtre : le processus de l’art consiste à faire des choses difficiles des habitudes, à rendre faciles les choses habituelles, puis à rendre belles les choses faciles
Donne un avis personnel sur les problèmes d’UI
Évoque les difficultés liées aux projets personnels
Exprime son respect pour les ingénieurs logiciel
Critique le perfectionnisme
Partage une réflexion personnelle
Mentionne que la famille et les enfants aident à dépasser le perfectionnisme
Écrire soi-même le logiciel est plus amusant et permet d’apporter des solutions plus simples
Affirme que la culture de l’obsession pour la nouveauté est à la racine du problème
Les psychologues classent les gens entre ceux qui veulent maximiser et ceux qui cherchent quelque chose d’assez bon
Il me semble qu’au lieu de « laisser ce qui est cassé en l’état », une formulation plus juste serait « apprendre à laisser de côté ce qui n’est pas important ».
Ce qui doit absolument être corrigé doit l’être.
Je comprends. Je pense qu’il faut savoir si l’on est en train d’embellir davantage son jardin ou si l’on accomplit vraiment un travail important, puis savoir lâcher prise.