Faire le travail, c’est faire le travail
(softwaredesign.ing)- L’action elle-même est la seule véritable exécution ; penser ou se préparer n’est pas agir
- Le texte souligne à répétition que planifier, apprendre, débattre, acheter des outils ne constituent pas le fait de « faire le travail »
- Essayer directement, même en échouant ou maladroitement, est la seule chose considérée comme une vraie mise en action
- Commencer, même modestement, est essentiel ; une préparation parfaite ou des conditions idéales ne sont pas nécessaires
- Le texte rappelle que l’attitude consistant à passer à l’action est au cœur de la création et du développement
Distinguer l’exécution de la non-exécution
- Le texte énumère que « penser, rêver, visualiser, se préparer » ne sont en rien « faire le travail »
- Ex. : « penser », « rêver », « imaginer le succès », « attendre d’être prêt »
- Parler, expliquer ou débattre n’est pas non plus considéré comme de l’exécution
- Cela inclut « l’expliquer à quelqu’un d’autre », « débattre en ligne », « annoncer qu’on va commencer »
Le piège de la préparation et de la consommation
- Écouter des podcasts, regarder des tutoriels, lire les cas d’autres personnes ne constitue pas de l’exécution
- Concevoir un système parfait, acheter des outils ou ranger son espace de travail n’est pas non plus vu comme de l’exécution
- Se réconforter avec la culpabilité ou l’impression d’être occupé ne relève pas non plus de l’action réelle
Les formes de la vraie exécution
- Faire en échouant, faire maladroitement, faire même à petite échelle : tout cela est reconnu comme le fait de « faire le travail »
- Même imparfait, le fait de réellement mettre la main à la pâte est ce qui compte
- Vers la fin, le texte affirme que « même écrire un billet de blog n’est pas faire le travail », proposant ainsi une conclusion introspective
Message essentiel
- Seule l’action est une vraie exécution ; tout le reste n’en est pas un substitut
- Commencer, même petit, accepter l’échec et essayer soi-même est la seule forme de progrès
- La dernière phrase, « Maintenant, il faut que je retourne travailler », symbolise une attitude d’exécution immédiate
2 commentaires
C’est une bonne formule pour les gens comme moi qui ont du mal à passer à l’action.
Réactions sur Hacker News
Le principe de « mal le faire » a complètement changé ma façon de penser
J’ai passé des semaines à essayer de concevoir l’architecture parfaite, puis j’ai fini par arrêter de planifier pour construire une version bricolée qui résolvait mon problème
Ce qui était frappant, c’est que cette première version m’a appris des choses qu’aucun plan n’aurait pu m’enseigner : ce qui compte vraiment pour les utilisateurs, les edge cases importants en conditions réelles, et ce que signifie réellement « suffisamment bon »
Le plus difficile, c’est d’accepter de déployer quelque chose dont on sait qu’il a des défauts. Mais la boucle de feedback issue de l’usage réel valait bien plus que des semaines de discussions hypothétiques
On voit ce genre de post partout sur les subreddits consacrés à la productivité ces jours-ci. Je doute qu’il soit vraiment réaliste de passer des semaines à planifier l’architecture d’un outil d’automatisation personnel
Quand on regarde l’historique des commentaires de l’auteur, on retrouve le même style encore et encore, ce qui ne m’inspire pas confiance
C’était vraiment fascinant à observer
On apprend énormément sur le problème et sur la programmation en général en implémentant réellement puis en refactorisant
Les abstractions qu’on imagine au départ sont presque toujours fausses. À mesure qu’on implémente, la structure change complètement, et au final on obtient un beau code totalement différent de l’idée initiale
L’idée est de construire la première version en étant prêt à la jeter, mais en pratique on ne la jette généralement pas : on l’améliore itérativement
Aujourd’hui, grâce aux outils et aux processus, on peut continuer à itérer
La structure interne demande elle aussi de l’itération et du prototypage, mais des éléments comme les structures de données, la gestion des erreurs, le logging et le naming doivent être décidés avec soin dès le départ pour pouvoir avancer vite ensuite
J’aime bien la phrase « Doing it badly is doing the thing »
C’est une leçon apprise sur HN : quand on bloque, il ne faut pas passer son temps à chercher à le faire parfaitement, il faut simplement commencer
Même si c’est bancal au début, à force d’améliorations progressives, on finit par voir l’ensemble plus clairement. C’est presque magique
Le premier est le conseil de Dan Harmon sur le writer’s block,
l’autre est « The Gap » d’Ira Glass
L’idée essentielle, c’est de ne pas attendre la perfection : il faut écrire même un premier jet médiocre, puis le corriger avec un œil critique
Du coup, maintenant, je dis volontairement « ce n’est pas encore prêt » jusqu’à ce que ce soit vraiment terminé
Moi, je fais d’abord quelque chose rapidement, puis je le peaufine, et à la fin je le réécris à neuf
L’important, c’est de ne pas tomber dans le perfectionnisme à l’étape beta
Si l’amélioration incrémentale est réellement efficace, peu importe qu’elle vienne d’un humain ou d’une IA
Dans mon ancienne entreprise, on appelait la direction l’association d’admiration du problème
Ils passaient leur temps à discuter des problèmes, à les analyser et à chercher des responsables, sans jamais vraiment les résoudre
Au final, ce qui comptait, c’était de faire réellement la chose
La meilleure approche consiste à combiner un vrai intérêt pour le problème et une volonté d’itérer sur les solutions
Le dogfooding, c’est-à-dire l’usage interne direct, est une bonne manière de maintenir cet équilibre
Il est important de prendre autant que possible les décisions dans le sens qui nous est favorable
Il y a moins de coordination pour les mises à jour, et les organisations où le travail réel est fait sont plus efficaces
Ce texte ressemble beaucoup à l’essai de strangestloop.io
En voyant le titre, j’ai eu une impression de déjà-vu ; puis j’ai cliqué, j’ai vu que c’était un autre site et que la publication datait de quelques jours plus tôt, ce qui m’a surpris
Le contenu est trop similaire pour que ce soit une simple coïncidence
Avant, je pensais que la préparation était essentielle, puis j’ai fini par comprendre qu’à un certain point la préparation devient une boucle infinie
Notre équipe a livré un produit en quatre mois avec une spec de deux pages, tandis qu’une équipe concurrente a passé huit mois à n’écrire que de la documentation avant d’être dissoute
20 % de planification permettent de traiter 80 % des problèmes. Au-delà, ce n’est souvent que de la rigueur déguisée en anxiété
Au final, la plupart des choses que j’ai apprises, je les ai apprises en livrant quelque chose d’un peu honteux puis en le corrigeant
C’était cité dans un ancien commentaire HN
L’analyse paralysante existe vraiment
Pour ne pas rester bloqué, il faut commencer. Il suffit de traiter d’abord le happy path, puis d’affiner les edge cases plus tard
Comme le coût du prototypage est faible aujourd’hui, il faut essayer sans avoir peur d’échouer
C’est précisément pour cela que les LLM sont étonnamment efficaces : ils passent immédiatement à l’exécution au lieu d’analyser
Même si le résultat n’est pas parfait, il est souvent suffisamment utile, et on peut l’optimiser ensuite si nécessaire
Avant de créer un framework, il faut avoir construit au moins trois vrais systèmes. C’est comme ça qu’on comprend ce qui est excessif ou insuffisant
Dire que c’est « suffisamment correct » peut relever de l’auto-illusion
Un prototype raté ne prouve pas qu’il n’y a pas de marché. C’est seulement le signal qu’il manquait quelque chose
Cet article véhicule presque exactement le même message que ce billet précédent
Cela avait déjà été évoqué dans une précédente discussion HN
À l’inverse, il arrive que « doing the thing » soit lui-même un mauvais choix
C’est pour ça que je reste attaché aux documents de conception et aux revues de code
À l’ère de la GenAI, il est devenu trop facile de « faire vite à peu près sans plan », donc il faut d’autant plus un contrepoids
On finit par perdre tout son temps à cause de la non-détermination et de la latence, et au bout du compte le vrai défi est de faire tenir l’économie unitaire
Dans The Remains of the Day, le fait de parler seulement de la chose au lieu de la faire est décrit comme un acte d’auto-satisfaction
Souvent, cela se réduit à une conversation qui donne bonne conscience sans rien accomplir de concret
À l’inverse, la planification, la préparation et la mise en place peuvent réellement aider à l’exécution