- Dans les grands projets techniques, il est essentiel de maintenir sa motivation et d’aller jusqu’au bout grâce à des résultats visibles au quotidien
- Au lieu de découper le projet en blocs vastes et flous, il faut le fragmenter en petites unités concrètes, et choisir une méthode qui permet de constater des progrès réels à chaque étape
- Au début, créer rapidement des démos grâce à une boucle de feedback serrée aide beaucoup à rester engagé et motivé
- Il est efficace de commencer par développer les fonctionnalités dont on a soi-même besoin, puis de les améliorer en continu par l’usage réel
- Mieux vaut privilégier le progrès plutôt que la perfection, et accumuler de façon répétée des petites réussites pour mener à bien les projets longs
Au point de départ
- Lorsqu’on lance un grand projet, la première difficulté est de décider par où commencer
- Si l’on essaie de prendre en compte tous les composants d’un coup, cela devient trop vague et l’on risque vite de perdre l’intérêt
- Il est important de commencer concrètement par une petite unité qui permet d’obtenir rapidement un résultat
- Chaque sous-projet doit être indépendant et fournir un signe clair d’achèvement
- Avec l’expérience, on perçoit mieux la forme d’ensemble et les sous-composants du projet
Produire des résultats dès le départ
- Au début, le travail comporte souvent peu d’éléments visibles, ce qui peut donner l’impression que rien n’avance
- Dans ce cas, il est important d’utiliser à bon escient des tests automatisés (par exemple des tests unitaires) pour obtenir des résultats visibles
- Par exemple, en créant un parseur de terminal, on peut vérifier immédiatement via des tests le résultat du parsing d’une chaîne d’entrée
- Le fait de voir régulièrement les tests passer procure en soi un sentiment d’accomplissement
- Ces petites réussites permettent d’accumuler en continu des preuves objectives de l’avancement global du projet
Créer rapidement des démos
- L’objectif initial n’est pas un sous-composant parfait, mais une implémentation suffisante pour une démo
- Il faut remettre à plus tard la complexité nécessaire à long terme (par exemple une base de données, des structures de données avancées, etc.) et donner la priorité absolue à une implémentation simple pour avancer vite
- Il faut toujours garder à l’esprit que « la perfection peut devenir l’ennemie du progrès »
- L’objectif est de produire une démo simple une à deux fois par semaine
- Même une démo incomplète permet de vérifier directement le résultat et d’obtenir un feedback intuitif, ce qui contribue fortement à la motivation
Développer pour soi-même
- Dans les projets personnels en particulier, il est important de commencer par les fonctionnalités dont on a soi-même besoin, puis de les adopter et les utiliser
- En l’utilisant directement, on ressent les points faibles et l’on améliore le projet en se concentrant sur les fonctionnalités réellement nécessaires, du point de vue d’un véritable utilisateur
- Au début de l’usage, des inconforts ou des bugs apparaissent, mais ils indiquent clairement ce qu’il faut faire ensuite
- La fierté d’utiliser un logiciel que l’on a soi-même écrit aide à poursuivre le projet
- Au départ, toutes les fonctionnalités non essentielles (défilement, sélection à la souris, onglets, etc.) sont omises
Comment empaqueter l’ensemble du projet
- Il faut découper le problème global en petits problèmes visibles. Chaque problème doit permettre de vérifier un résultat concret
- Chaque petit problème n’est résolu que jusqu’au niveau suffisant pour produire une démo, puis l’on passe au suivant
- Il faut créer une démo fonctionnelle le plus vite possible, puis ajouter les fonctionnalités de façon itérative
- On implémente en priorité les fonctionnalités qui ont du sens pour son propre usage
- Si nécessaire, on améliore chaque composant de manière itérative et l’on fait tourner ce processus en boucle
Conclusion
- Cette méthode permet de s’auto-motiver et d’aller jusqu’au bout de projets variés, qu’ils soient personnels, collectifs, professionnels ou académiques
- L’accent n’est pas mis sur le déploiement ou le tooling, mais sur ce qui permet concrètement de maintenir une motivation durable
- La même méthode ne convient pas à tout le monde, mais des résultats visibles restent la force la plus importante pour mener à bien les projets de longue haleine
- Il est essentiel de comprendre ses propres centres d’intérêt et sa manière de se motiver, puis de construire un processus de travail adapté
1 commentaires
Avis Hacker News
Je suis d’accord avec tout ce qui est avancé dans l’article, et j’aimerais ajouter un point : l’importance d’une boucle de feedback rapide
Pouvoir faire un changement et en voir immédiatement le résultat est extrêmement motivant
Quand on peut bricoler le code de façon ludique et observer les effets, beaucoup de problèmes disparaissent ou se transforment en quelque chose de facile à résoudre
Sur les gros projets, j’ai clairement constaté une corrélation entre la facilité de configuration et d’exécution, et la quantité de problèmes sur le projet (bugs, retards, etc.)
Elle parle justement des boucles de feedback
Lien YouTube
Je réfléchis à ajouter des tests e2e pour les bugs que j’ai trouvés, afin de vérifier qu’ils sont réellement corrigés
Quand on veut essayer ou corriger quelque chose, si rien que le setup prend plusieurs heures, on perd toute motivation et on finit par repousser
C’est pour ça que j’aime les langages comme lisp, qui ont un REPL réellement utilisable
Il y a cette satisfaction immédiate de voir le résultat sur-le-champ
Dès qu’on perd la motivation, le projet s’évapore
Faire en sorte que le développement soit une expérience agréable est donc presque le facteur le plus important
À mon avis, l’expérience peut au contraire devenir un obstacle
Je vois souvent des ingénieurs seniors creuser très loin pour construire quelque chose de parfait, puis au moment de faire une démo, le résultat est finalement assez médiocre
L’implémentation est bonne, mais la fonctionnalité ou le produit lui-même est complètement raté
Parfois, j’ai envie d’éteindre mon cerveau et d’écrire du code bancal sans réfléchir
Avant, je faisais beaucoup de projets pour m’amuser, et je mettais parfois tout le code source dans un seul fichier
Je ne me souciais pas de modulariser, c’était amusant et ça fonctionnait
Mais maintenant, finir ne serait-ce qu’un petit projet ludique est devenu vraiment difficile
J’ai l’impression que cela vient du fait qu’après l’avoir déjà fait une fois, on a tendance à vouloir ajouter tout un tas de fonctionnalités inutiles
Par exemple, en participant à des défis de code comme Advent of Code, où les premiers problèmes sont simples et où ce n’est qu’ensuite qu’on a besoin d’optimisation ou d’algorithmes complexes
Ou bien avec pico-8, où les contraintes empêchent de coder trop longtemps
Sinon, tenter l’expérience dans un environnement limité dans le temps, comme un hackathon ou une game jam, peut aussi aider
Des personnes moins expérimentées peuvent oublier tous les « best practices » usants de leurs anciens langages et essayer librement de nouvelles choses
Je conçois moi-même les tables de DB, et je laisse le LLM gérer plus librement la partie implémentation
J’ai trouvé marquante l’idée que l’objectif des premiers sous-projets n’est pas de produire des sous-composants « terminés », mais des sous-composants « suffisamment bons » pour permettre de passer à l’étape suivante
Pour appliquer réellement cette approche, j’ai compris qu’il faut forcément « omettre » quelque chose
D’autres ont dit que, dans ce mode, ils ignoraient la modularisation du code, mais moi, garder un code propre me donne au contraire de la satisfaction et de la motivation
Donc je vais plutôt « omettre » les algorithmes, les structures de données et la performance
Au fond, l’idée est qu’il faut clairement laisser de côté quelque chose, mais que si cette chose fait partie de ce qui me motive, alors il ne faut pas la sacrifier
Une démo joue un rôle intermédiaire entre le développement logiciel (la programmation) et son explication par écrit (la documentation)
À travers les démos, je peux continuellement vérifier mes hypothèses sur ce que mon projet doit faire, et cela devient une sorte de mécanisme de feedback
Les démos restent dans le temps, ce qui permet d’entrer dans une boucle itérative où l’on voit tout de suite quand une fonctionnalité casse et où on la corrige
C’est comme ça que je travaille personnellement sur le moteur de jeu que je développe
Exemple de démos sur GitHub
J’aimerais que cette façon de faire devienne du simple bon sens
On a l’impression qu’il est surtout centré sur les projets personnels
Moi, ce qui m’intéresse, c’est de savoir comment bien mener un grand projet technique en équipe, où tout le monde travaille vers un même objectif et où les choses se terminent correctement
En presque 15 ans de travail, je n’ai jamais vu un projet technique sans dépassement de budget, retard, manque de fonctionnalités ou burnout
À l’inverse, s’il existe des exemples de grands projets de ce type réellement bien menés, j’aimerais beaucoup qu’on partage des liens ou des recommandations de lecture
Le dépassement de budget est courant, tant qu’on n’a pas réellement épuisé tout l’argent
La plupart du temps, cela revient juste à quelqu’un qui râle parce que son estimation était fausse
Même chose pour les retards : sauf s’il y a une échéance absolument impérative, ce n’est pas forcément grave
En réalité, il vaut mieux éviter de planifier des événements liés au calendrier, comme une grande campagne de communication, tant que le projet n’est pas presque terminé
Le manque de fonctionnalités relève aussi, au fond, d’un problème d’attentes
Le vrai problème, c’est que les gens finissent complètement vidés et en burnout
C’est au moins cela qu’il faut absolument éviter
Personnellement, j’en viens à apprécier de plus en plus le Scaled Agile Framework
Je l’utilise comme un framework, c’est-à-dire comme une sorte d’« épouvantail » que j’adapte au contexte
Cela m’a aidé à explorer des sources plus profondes et à tirer mes propres conclusions
J’ai appris que le vrai succès commence par une compréhension claire du « pourquoi construit-on cela ? »
Quand l’objectif n’est pas clair, on ne peut pas prioriser, ni même savoir par où commencer
Cette clarté aide énormément à décider « quoi construire et quand », et permet parfois aussi de décider de « ne rien construire du tout »
L’autre point important, ensuite, c’est l’empathie
Il faut vraiment comprendre le problème du client de son point de vue et proposer une solution
Il ne s’agit pas simplement de faire tout ce que le client demande, mais de comprendre précisément sa douleur principale pour livrer quelque chose qui a une vraie valeur
La vraie raison pour laquelle la plupart des projets échouent, c’est que l’équipe passe trop de temps à construire la mauvaise chose
Si l’on reste constamment concentré sur ce qui est nécessaire, sur ce que les gens veulent réellement ou sur ce pour quoi ils seraient prêts à payer, alors bien plus de projets pourraient aboutir avec succès
Il y a vraiment beaucoup de gens qui tombent dans la paralysie de l’analyse face à un gros projet
Ce qui est vraiment difficile, c’est de finir
Quand on construit un logiciel qu’on va utiliser soi-même, on peut résoudre ses propres problèmes
On peut aussi découvrir les bugs du logiciel en l’utilisant directement
J’ai d’ailleurs trouvé beaucoup de bugs en construisant et en utilisant moi-même un serveur web
Une culture de développement focalisée, itérative, et orientée vers des résultats qui fonctionnent en permanence