Massimo Russo
Tu passes des années à maîtriser Vue.js. Tu codes vite. Ton refactoring est clean. Tes pull requests font envier tes collègues. Et pourtant, tu as cette sensation bizarre : tu piétines. Tu apprends une nouvelle techno chaque an, tu lis la doc de Vite à 23h, tu debug des race conditions en prod. Mais tu n'évolues pas.
Pourquoi ?
Parce que tu confonds être un meilleur développeur avec avoir un meilleur impact.
Ce n'est pas la même chose. Et c'est cette confusion qui transforme les devs en exécutants permanents.
La narration est séduisante : "Si je maîtrise React, je serai meilleur. Si je comprends les Closures en profondeur, je vais progresser. Si j'apprends TypeScript avancé, ça changera ma carrière."
Faux.
J'ai passé des années à devenir expert en Vue.js. Je livrais du code propre, rapide, maintenable. Zéro plainte. Mais je ne savais pas pourquoi les features que je construisais existaient. Parfois, elles n'avaient aucun impact sur le produit. Parfois, elles cassaient l'UX pour une optimisation de 50ms sur le bundle.
La technique est un outil. L'impact est le produit.
Un développeur qui maîtrise mal TypeScript mais comprend les priorités utilisateurs va avoir 10x plus d'influence qu'un expert TypeScript qui code dans le vide.
À chaque tâche, pose-toi cette question avant de toucher au clavier :
"Quel problème utilisateur je résous, vraiment ?"
Pas "quel problème technique." Quel problème utilisateur.
Si tu ne peux pas répondre en une phrase, tu n'as pas compris la tâche. Va poser la question à quelqu'un qui l'a créée.
Ensuite, avant chaque discussion de fonctionnalité, commence par :
"Quel est l'objectif derrière cette feature ?"
Pas "Comment on la code." D'abord : pourquoi elle existe. Comment ça va améliorer le produit ? Comment ça change les KPIs ?
Si tu peux répondre à ça, tu arrêtes de penser comme un exécutant. Tu commences à penser comme quelqu'un qui construit.
Tu arrives le matin. Tu vois un ticket : "Optimiser le rendu des listes de 10k éléments."
Ton cerveau de dev se met en marche. Redux ? Virtualisation ? Memoization agressif ? Web Workers ? Tu commences déjà à coder une solution complexe, élégante, technique.
Stop.
As-tu vraiment compris le problème ?
Souvent, trop souvent, on se lance dans des solutions complexes pour des problèmes qui n'existent pas. Des faux bugs. Des optimisations prématurées. Des architectures pensées pour un scale futur qui ne viendra jamais.
Définis le problème en une phrase simple.
Si tu dois utiliser un tableau ou un diagramme pour l'expliquer, c'est que tu ne l'as pas compris.
"Les listes avec 10k éléments freezent pendant 5 secondes" : c'est simple. Problème clair.
Ensuite, challenge ta solution :
Un problème bien défini admet souvent une solution élégante et simple. Si ta solution est complexe pour un problème simple, tu n'as pas compris le problème.
"Les vrais architectes codent des trucs complexes. Les bons systèmes ont des patterns sophistiqués. Si c'est simple, c'est que j'ai pas assez réfléchi."
Je suis passé par là. J'ai cru que devenir architecte, c'était apprendre les patterns SOLID par cœur, implémenter des Factories élégantes, des Decorators imbriqués, des Strategies polymorphes.
Les meilleurs architectes que j'ai rencontrés m'ont tous dit la même chose :
Simplifier, c'est un art.
Et contrairement à la complexité (qui est facile), la simplicité demande de vraies compétences. Ça demande de questionner chaque couche, chaque abstraction, chaque pattern. De se demander : "Est-ce que c'est vraiment nécessaire ?"
Un système simple, flexible et scalable est 100x plus puissant qu'un système complexe, "entreprise-grade" et impénétrable.
La règle des trois phrases.
Si tu ne peux pas expliquer ta solution en trois phrases simples, elle est trop complexe.
Essaie :
"On stocke les données utilisateurs dans un état global (Pinia). Quand un utilisateur change ses infos, on met à jour l'état et on synchro avec le serveur. Les autres composants qui en dépendent se réactualisent automatiquement."
C'est simple. Un junior comprend. Un senior voit la logique. Pas de jargon. Pas de pattern name-dropping.
Si tu dois dire : "On utilise une architecture hexagonale avec un pattern Mediator et du CQRS..." : c'est un drapeau rouge.
Ensuite, quand tu revois du code (le tien ou celui des autres) :
Demande-toi : "Comment ça pourrait être plus simple ?"
Le refactor n'est pas un luxe. C'est une discipline architecturale.
Ces trois erreurs sont tellement communes qu'elles paraissent invisibles. On les absorbe dès le démarrage de notre carrière et on ne se pose jamais la question.
Mais voilà le truc : tu ne progresseras jamais en restant dans le même cadre mental. Les frameworks changeront. Les techs deviendront obsolètes. Mais le mindset ?
Le mindset te suivra toute ta carrière.
Un dev qui pense en "impact utilisateur" va s'adapter à n'importe quel tech stack.
Un dev qui pense en "problèmes d'abord" va écrire du code pertinent, peu importe la complexité.
Un dev qui comprend que "simple = puissant" va construire des systèmes qui tiennent 10 ans.
Tu peux continuer à optimiser ta maîtrise technique. C'est cool. Mais sachant maintenant que ce n'est pas ce qui te fait progresser.
Ce qui te fait progresser, c'est de penser comme un stratège. Comprendre les problèmes. Chercher l'impact. Valoriser la simplicité.
Les meilleurs développeurs que j'ai rencontrés n'étaient pas nécessairement les plus experts en techno. C'étaient ceux qui avaient compris que le code n'était qu'un moyen.
Et le moyen ? C'est résoudre les vrais problèmes.