On n’obtient pas de promotion avec la simplicité
(terriblesoftware.org)- Dans la culture de l’ingénierie logicielle, ceux qui construisent des systèmes complexes sont davantage reconnus, tandis que ceux qui choisissent une solution simple restent peu valorisés
- Dans les évaluations de promotion, les entretiens et les revues de conception, la complexité est souvent prise à tort pour de l’« impact », ce qui renforce la tendance à ajouter des abstractions et de l’extensibilité inutiles
- Une implémentation simple reste souvent une « réussite invisible », alors qu’une structure complexe remplit facilement un dossier de promotion grâce à un récit flatteur et à une documentation abondante
- La véritable maîtrise ne consiste pas à utiliser davantage d’outils, mais à avoir le discernement et la confiance nécessaires pour savoir quand écarter la complexité
- Les ingénieurs comme les responsables doivent rendre la simplicité visible et créer des systèmes d’évaluation et de récompense qui la reconnaissent officiellement
Simplicité vs complexité : l’asymétrie du récit de promotion
- Exemple de deux ingénieurs dans la même équipe : Engineer A livre une fonctionnalité en quelques jours avec 50 lignes de code concises ; Engineer B met trois semaines à terminer en introduisant une nouvelle couche d’abstraction, un système pub/sub et un framework de configuration
- Le travail d’Engineer B peut être décrit dans un dossier de promotion comme « conception d’une architecture évolutive orientée événements, introduction d’une couche d’abstraction réutilisable, mise en place d’un framework de configuration »
- Celui d’Engineer A se résume à trois mots : « implémentation de la fonctionnalité X »
- En réalité, c’était le meilleur travail, mais comme il a été rendu simple en apparence, il devient une contribution invisible
- Personne n’est promu pour la “complexité évitée” — si la complexité paraît intelligente, c’est parce que le système d’évaluation est conçu pour la récompenser
Comment la complexité est renforcée dans les entretiens et les revues de conception
- Dans un entretien de system design, si vous proposez une solution simple (une base de données unique, une API intuitive, une couche de cache), l’intervieweur met la pression avec : « Et si vous aviez dix millions d’utilisateurs ? »
- Plus on ajoute de services, de files de messages et de sharding, plus on a l’impression de satisfaire l’intervieweur
- La leçon retenue par le candidat : « une réponse simple ne suffisait pas »
- L’intervieweur peut avoir des raisons légitimes d’insister (évaluer la réflexion sous pression, la compréhension des systèmes distribués), mais le message perçu par le candidat reste : « la complexité impressionne »
- Dans les revues de conception aussi, le schéma se répète : face à la question « Ne faudrait-il pas anticiper l’avenir (future-proof) ? », on finit par ajouter des couches et des abstractions inutiles
- Non pas parce que le problème l’exige, mais parce que c’est ce que la salle attend
- On voit souvent des abstractions créées pour éviter quelques lignes de code dupliquées, qui au final rendent la compréhension et la maintenance plus difficiles
- Le code avait l’air plus « professionnel », mais les utilisateurs n’ont pas reçu la fonctionnalité plus vite, et l’ingénieur suivant a passé une demi-journée à comprendre l’abstraction avant de pouvoir modifier quoi que ce soit
Complexité justifiée vs complexité inutile (Unearned Complexity)
- La complexité n’est pas un problème en soi — traiter des millions de transactions nécessite des systèmes distribués, et quand 10 équipes construisent le même produit, il faut des frontières de service
- Le problème, c’est la complexité inutile : il y a une différence entre « il faut du sharding parce qu’on a atteint les limites de la base de données » et « faisons du sharding maintenant parce qu’on pourrait atteindre ces limites dans trois ans »
- Le code et l’architecture des ingénieurs qui comprennent cela donnent une impression d’évidence : rien de magique, rien d’astucieux à exhiber, et aucun sentiment d’être idiot parce qu’on ne comprend pas
- La vraie voie vers le niveau senior ne consiste pas à apprendre toujours plus d’outils et de patterns, mais à savoir quand ne pas les utiliser — n’importe qui peut ajouter de la complexité, mais l’en retirer demande de l’expérience et de la confiance
Pistes d’action pour les ingénieurs
- Il faut rendre la simplicité visible — le travail ne parle pas de lui-même, parce que le système d’évaluation n’est pas conçu pour l’entendre
- Au lieu d’écrire « implémentation de la fonctionnalité X », écrivez plutôt : « après avoir évalué trois approches, dont une architecture orientée événements et une couche d’abstraction personnalisée, j’ai conclu qu’une implémentation simple répondait aux besoins actuels et prévisibles ; elle a été livrée en 2 jours et a tourné 6 mois sans incident »
- Décider de ne pas construire quelque chose est aussi une décision, et une décision importante — elle doit être documentée comme telle
- En revue de conception, face à « ne faut-il pas anticiper l’avenir ? », ne cédez pas immédiatement ; expliquez plutôt : « l’ajouter plus tard coûterait tant, l’ajouter maintenant coûterait tant, il vaut mieux attendre »
- Ce n’est pas de la contradiction, c’est la preuve que l’analyse a bien été faite
- Parlez directement à votre manager : « je veux que la façon de documenter mon travail reflète non seulement le code, mais aussi les décisions que j’ai prises »
- Du point de vue du manager aussi, cela lui donne un vocabulaire pour défendre ce travail
- Si, malgré tous ces efforts, l’équipe ne promeut que ceux qui construisent les systèmes les plus sophistiqués, c’est aussi une information utile — certaines organisations accordent réellement de la valeur à la simplicité, tandis que d’autres le disent tout en récompensant l’inverse
Pistes d’action pour les responsables d’ingénierie
- Définir les incitations est de la responsabilité des responsables — la plupart des critères de promotion sont conçus pour récompenser la complexité, et l’« impact » est souvent mesuré à l’échelle et à l’étendue de ce qui a été construit
- Il faut évaluer non seulement ce qui a été construit, mais aussi ce qui a été évité
- En revue de conception, au lieu de demander « avez-vous pris en compte la scalabilité ? », demandez plutôt : « quelle est la version la plus simple que l’on peut mettre en production, et quels signaux concrets indiqueraient qu’une solution plus complexe devient nécessaire ? »
- Cette seule question change la donne : la simplicité devient l’option par défaut, et la charge de la preuve revient à la complexité
- Lors des discussions de promotion, face à un dossier composé d’une liste de systèmes impressionnants, il faut aussi demander : « était-ce vraiment nécessaire ? Le système pub/sub était-il réellement utile, ou avait-il surtout belle allure sur le papier ? »
- Lorsqu’un membre de l’équipe livre quelque chose de propre et simple, il faut l’aider à construire son récit — « a évalué plusieurs approches et choisi la plus simple pour résoudre le problème » ne devient un argument convaincant pour une promotion que si le responsable le traite réellement comme tel
- Faites attention à ce que vous célébrez publiquement dans les canaux d’équipe — si vous ne félicitez que les grands projets complexes, les gens s’optimiseront pour cela
- Il faut reconnaître l’ingénieur qui a supprimé du code, celui qui a dit « ce n’est pas encore nécessaire » et qui avait raison
10 commentaires
design guidé par le CV...
Commentaires sur Hacker News
Lors d’une question d’entretien, on m’a présenté une situation où deux personnes s’échangeaient un tableur par e-mail
J’ai répondu que je basculerais sur Google Sheets, mais l’intervieweur semblait vouloir que je conçoive moi-même l’outil
C’était gênant sur le moment, et je ne sais toujours pas vraiment quelle leçon il fallait en tirer
Il aurait fallu reconnaître la bonne réponse, puis enchaîner avec : « c’est un scénario hypothétique pour évaluer la conception technique, concevons donc un nouveau système »
Si le candidat n’arrive pas à entrer dans ce cadre, cela peut alors être évalué comme un autre signal
À ma place, je demanderais : « Voulez-vous que je parte du principe qu’aucune solution existante n’est disponible et que je conçoive quelque chose de neuf ? »
C’est comme une version système design des débats d’algorithmes où l’intervieweur ne veut entendre que la réponse qu’il attend
C’était en réalité la bonne décision, mais Patrick Collison l’a appelé lui-même pour lui dire : « tu n’as pas réussi l’entretien, mais tu comprends l’intention derrière ? »
Il a finalement repassé l’entretien et l’a réussi
C’était une anecdote qui montrait l’importance de comprendre l’objectif de l’entretien
Une grande compagnie de ferries gérait les positions des navires et l’affectation du personnel avec Google Sheets, et mon ami disait : « ce n’est pas digne d’un grand groupe »
Mais moi, je trouvais admirable qu’ils aient résolu le problème avec un outil déjà éprouvé
Grâce à cela, ils pouvaient fonctionner sans équipe de développement interne ni sous-traitance coûteuse
Ce fut une expérience qui m’a appris à enterrer profondément mon orgueil
Il faut d’abord amener l’autre personne à expliquer précisément ce qui ne va pas, puis seulement ensuite commencer la conception technique
Il peut y avoir toutes sortes de raisons pour ne pas utiliser Sheets — limites fonctionnelles, restrictions d’accès en Chine, politique interne de l’entreprise, problèmes réseau, etc.
Le client veut peut-être déjà une solution sur mesure pour ce type de raison
Autrement dit, le rôle du développeur n’est pas simplement de dire « utilisez Google Sheets », mais de comprendre le contexte du client
Les outils de coding IA aggravent le problème de façon plus subtile
On peut désormais générer une architecture complexe en cinq minutes, mais le coût de maintenance reste le même
Au final, des structures plus tape-à-l’œil sont produites rapidement, et les documents pour obtenir une promotion sont eux aussi vite rédigés
Mais en pratique, personne ne comprend complètement ce code
Le vrai critère de simplicité, c’est : « la personne suivante peut-elle le comprendre sans poser de questions ? », et le code généré par l’IA ne passe pas vraiment ce test
Maintenant, cela ne fera qu’empirer
C’est pourquoi je prends la solidité de la culture de compréhension du code dans l’organisation comme critère de choix de carrière
Je ne veux plus revivre une situation où personne ne connaît le système
Si l’objectif est de résoudre un problème, alors qu’il s’agisse d’un outil créé par l’IA ou d’un outil acheté, il doit au final résoudre le problème
Mais si un produit du marché ne convient pas, on verra forcément plus de solutions sur mesure générées directement
Simplement, si personne ne les comprend, la personne suivante en recréera encore une autre
Cela dit, le fait de rapprocher les utilisateurs et les créateurs pourrait aussi être une amélioration
Par exemple, indiquer dans
AGENTS.mddes consignes comme « KISS » ou « YAGNI » peut aiderLe problème, c’est que la « personne suivante », au final, c’est souvent moi-même dans six mois
L’IA se heurte au même problème à cause des limites de la context window
Beaucoup de développeurs ne jurent que par les stacks populaires, sans réfléchir à la facilité d’exploitation
L’IA ne vous dira pas non plus : « là, c’est du surdesign »
Si vous voulez Kubernetes et ElasticSearch, elle vous les produira tels quels
Pour avoir travaillé à la fois dans la FAANG et dans des startups, je dirais que la clé est l’équilibre entre complexité et simplicité
Dans les grandes entreprises, des bricolages temporaires peuvent nuire à la productivité de milliers de personnes,
tandis que dans une startup, une infrastructure excessive peut couler l’entreprise
Un ingénieur vraiment expérimenté, c’est quelqu’un qui sait distinguer ces deux situations et choisir les bons compromis grâce à son expérience
Quand je travaillais chez Amazon (2005~2008), il y avait deux récompenses emblématiques de la culture d’entreprise
Le prix « Just Do It » symbolisait la résolution proactive des problèmes, et le prix « Door Desk » symbolisait la frugalité et la simplicité
Il y a même une anecdote où un employé qui avait retiré une télévision inutile a reçu un prix… et cette télévision comme récompense
La simplicité comme métaphore restait assez ambiguë dans la pratique
Pour défendre la simplicité, il faut la formuler dans le langage du business
Avec des expressions comme « 80 % d’incidents en moins », « 40 % de coûts en moins », « 33 % de performance en plus »
La simplicité en soi n’est pas évaluée, mais ses résultats, eux, le sont fortement
J’ai transformé un refactoring en modèle de coût, mesuré des KPI et réduit le MTTR de 60 %
Il faut montrer ce genre de chiffres pour être reconnu
En tant que manager, je préférais le code simple
Mais c’était aussi parce que l’équipe était composée de personnes expérimentées
Dans une équipe moins aguerrie, on peut vite se retrouver dans une situation comme The Parable of The Toaster
Avec l’âge, on devient plus enclin à résister à la complexité
Mais le leadership interprète souvent cela comme : « il s’y oppose parce qu’il ne comprend pas »
Les projets qui ont duré le plus longtemps étaient ceux qui étaient simples et faciles à remplacer
Les outils d’IA facilitent encore cette approche — on peut expérimenter des composants dans des projets d’exemple indépendants, puis intégrer le code validé dans le projet principal
Je ne connecte pas directement l’IA dans les environnements sur réseau interne, mais cette méthode est très utile
C’est pourquoi je propose : « on peut faire quelque chose de complexe aussi, mais commençons d’abord par une version simple »
La plupart du temps, cette version simple finit par devenir du code de production exploité pendant des années
Un développeur qui livre rapidement une solution simple peut utiliser le temps restant pour implémenter plusieurs autres fonctionnalités
À l’inverse, quelqu’un qui s’acharne sur une solution complexe peut passer des semaines sur une seule fonctionnalité
Au final, dans les indicateurs de productivité, l’approche simple paraît plus attractive
Moi aussi, j’ai construit ma carrière non pas comme quelqu’un qui avait de « grandes idées », mais comme quelqu’un qui produit des résultats de façon constante
L’un des entretiens dans notre entreprise porte sur la conception d’un système de bibliothèque publique
Au départ, on commence à l’échelle d’une petite bibliothèque de ville, puis on élargit le scénario à l’échelle nationale
La meilleure réponse était : « même à l’échelle maximale, un serveur de milieu de gamme avec Postgres suffit largement »
En pratique, 10 ou 10 000 ne changent pas grand-chose, et il arrive souvent que des intervieweurs inexpérimentés se contentent de lire le prompt
Ensuite, l’excès d’infrastructure et le développement orienté CV ont aggravé le problème
Je pense qu’au final, l’IA est surtout un outil qui amplifie les capacités de l’utilisateur
Pour les développeurs expérimentés, elle améliore la productivité, mais pour les personnes moins aguerries, elle devient un outil qui propage rapidement la confusion
Au contraire, elle a tendance à ajouter des fonctions wrapper inutiles et des conversions de types
J’ai plutôt l’impression que l’IA va « dans le sens d’ajouter plus de code »
En revanche, la montée d’un « vibe coding » superficiel m’inquiète
Je ne pense pas que les propositions évoquées dans cet article soient dénuées de sens, mais je pense qu’elles ont trop peu de chances face à la « grande conception ». C’est tellement, tellement plus facile à expliquer de ce côté-là :(
Les recruteurs que j’ai rencontrés semblaient eux aussi préférer la complexité.
Je n’irai même pas jusqu’à espérer qu’on valorise la simplicité. En réalité, il arrive même qu’on soit promu pour avoir réparé les dégâts causés en compliquant inutilement les choses.
La surarchitecture destinée à gonfler l’image de compétence, plutôt qu’une conception au service du produit, est monnaie courante.
Je pense qu’il faut que l’évaluateur ait une bonne compréhension.
Et il est vrai aussi qu’il faut écouter suffisamment les explications.
Si la personne qui est montée en poste est capable d’évaluer ce genre de choses, tout va bien. Mais comme, au départ, ce n’est pas le cas, ce genre de contribution n’est pas évalué correctement, et du coup ces personnes-là ne peuvent pas monter...
C’est un cercle vicieux...
Du point de vue de l’entreprise, j’ai l’impression que c’est en réussissant comme ingénieur équilibré et en montant en responsabilité qu’on peut aussi défendre les bons principes d’ingénierie et être un bon ingénieur.
La plupart du temps, dans la réalité, ce n’est pas plutôt « savoir simplement implémenter des fonctionnalités » vs « savoir concevoir avec extensibilité tout en gérant bien les compromis » ?
Même si le travail a été fait de manière complexe, on peut au final dire qu’il s’agit de l’implémentation de la fonctionnalité X.
La différence, c’est la manière dont on le présente à l’évaluateur.