L’ingénieur qui dit simplement « non » était un phénomène du ZIRP
(seangoedecke.com)- L’ingénieur qui dit simplement « non » est un archétype senior dont le rôle consiste essentiellement à bloquer les changements de code, retarder les fonctionnalités complexes et faire en sorte que le moins de code possible soit écrit
- Pendant la période du ZIRP, grâce aux taux bas et à l’expansion des embauches, les pertes de productivité comptaient moins, et bloquer les propositions techniques radicales était utile aux entreprises
- Après la hausse des taux, les entreprises technologiques ont licencié 5 à 20 % de leurs ingénieurs et, en privilégiant le chiffre d’affaires plutôt que le cours de Bourse, ont réduit les protections qui remplaçaient le « non »
- Les LLM ont accru la pression avec les PR générées par IA et du code suffisamment exploitable, mais le changement fondamental ne vient pas de l’IA : il vient des incitations économiques transformées par la fin du ZIRP
- Ce rôle ne disparaît pas, mais il convient mieux à des domaines de pur engineering et doit accepter un périmètre plus restreint et une visibilité moindre qu’au cours des années 2010
Le rôle de « l’ingénieur qui dit simplement non »
- L’ingénieur qui dit simplement « non » est un archétype situé entre l’ingénieur senior et staff, dont le rôle consiste surtout à ralentir le développement des fonctionnalités, empêcher les changements qui augmentent la complexité et faire en sorte que le moins de code possible soit écrit
- À l’opposé, l’ingénieur qui dit simplement « oui » privilégie la vitesse, approuve par défaut les changements de code, accorde plus d’importance au MTTR qu’au MTBF et tend à déployer beaucoup de code
- La plupart des ingénieurs se situent entre ces deux extrêmes, mais ici l’accent est mis sur ceux qui s’identifient fortement au rôle du « non »
- À l’ère de l’IA, il faut rejeter en masse non seulement les PR de juniors, mais aussi le code généré par IA, et il arrive que le code soit produit par un manager ou un VP, ce qui rend le refus politiquement difficile
- Pour la première fois de leur carrière, ces profils subissent une forte pression pour abaisser leurs critères et dire « oui », mais la cause profonde est moins l’IA elle-même que la fin du ZIRP
L’environnement créé par le ZIRP
- ZIRP est l’acronyme de « politique de taux zéro » et désigne l’époque du développement logiciel, entre 2008 et 2022, où les banques prêtaient aux entreprises à des taux proches de zéro
- Les investisseurs injectaient cet argent emprunté dans à peu près n’importe quoi, et les entreprises technologiques avaient tout intérêt à continuer d’embaucher des ingénieurs pour des projets à faible risque et forte récompense potentielle
- Les entreprises qui réussissaient faisaient passer leurs effectifs d’ingénieurs de quelques dizaines à plusieurs milliers, en les occupant à des projets open source périphériques, des migrations techniques sans fin ou des réécritures dans d’autres langages
- Pour les ingénieurs logiciels, c’était une période de fort pouvoir de négociation, où presque n’importe quel travail était très bien rémunéré
- Les dirigeants voyaient leurs équipes grandir trop vite pour pouvoir suivre les détails, et comme l’augmentation du nombre d’ingénieurs aidait en soi le cours de Bourse, beaucoup d’activités n’étaient pas perçues comme un problème majeur
- Si trop d’ingénieurs avançaient librement, les systèmes pouvaient devenir ingérables, et c’est là que l’ingénieur qui dit simplement « non » devenait utile à l’entreprise
Pourquoi le « non » avait de la valeur pendant le ZIRP
- Comme la perte de productivité n’était pas un gros problème, une entreprise pouvait supporter qu’une moitié de ses ingénieurs tourne dans une boucle où elle propose des changements puis se les voit refuser
- Ce mode de fonctionnement avait aussi pour effet d’empêcher les ingénieurs de toucher aux systèmes critiques pour le business
- Il aidait aussi à contenir les 5 % d’ingénieurs qui, grisés par leur liberté technique, proposaient des idées radicales du genre migrer vers une base de données maison
- La réputation d’une entreprise aux standards techniques très élevés était favorable au recrutement, et pendant la période ZIRP, toutes les entreprises technologiques recrutaient en permanence
- La formule selon laquelle « les juniors produisent beaucoup de code, les seniors en produisent peu, et les staff en suppriment » séduit parce qu’elle suggère que les experts n’ont presque plus besoin d’agir, mais elle est trompeuse : un staff engineer doit aussi être capable de produire très vite beaucoup de code fonctionnel quand c’est nécessaire
Ce qui a changé après la fin du ZIRP
- Quand les banques ont relevé les taux, presque toutes les entreprises technologiques ont immédiatement licencié 5 à 20 % de leurs ingénieurs
- Maintenir de grosses organisations d’ingénierie gonflées pour soutenir le cours de Bourse n’était plus rentable, et les entreprises ont dû gagner de l’argent pour de vrai
- Ici, « gagner de l’argent » ne signifie pas forcément être rentable, mais au minimum générer du chiffre d’affaires
- Reconnaître publiquement que des centaines d’ingénieurs travaillaient sur des choses non rentables n’était pas une bonne explication à donner pour des licenciements
- Comme la fin du ZIRP a coïncidé à peu près avec l’ascension de ChatGPT, les entreprises ont pu présenter ces licenciements comme une conséquence de la puissance de l’IA
- Le message « grâce à cette technologie transformatrice, nous pouvons livrer 10 fois plus de valeur avec deux fois moins d’ingénieurs » frappe fort, mais si c’était vraiment le cas, on peut se demander pourquoi ne pas conserver les ingénieurs pour livrer 20 fois plus de valeur
Des entreprises plus focalisées, et moins de protection
- Les entreprises technologiques sont aujourd’hui plus focalisées qu’à n’importe quel moment des 20 dernières années, et cherchent désormais avec acharnement de nouvelles capacités et fonctionnalités capables de rapporter de l’argent, plutôt que de multiplier les initiatives aléatoires
- Ce nouvel environnement est clairement défavorable à l’ingénieur qui dit simplement « non »
- Autrefois, ce type d’ingénieur bénéficiait d’un soutien implicite de la direction, et même en cas de plainte on pouvait balayer le sujet avec un « on sait ce qu’il fait ; s’il a dit non, on lui fait confiance »
- Ce soutien a désormais disparu, et le même comportement est critiqué par la direction, voire activement contredit
- On leur demande d’être davantage des team players, de trouver un moyen de dire oui, ou bien on cesse de les consulter sur les décisions importantes
- Des comportements auparavant récompensés se traduisent désormais par de mauvaises évaluations, et les changements culturels suivent parfois avec quelques années de retard les changements d’incitations économiques
- Cette évolution ne dépend pas de l’IA : même si les LLM n’avaient pas émergé cette décennie, les entreprises auraient quand même licencié des ingénieurs, et ceux qui tenaient le rôle du « non » se demanderaient toujours pourquoi les mêmes comportements sont désormais sanctionnés
Le choc supplémentaire apporté par l’IA
- Si le ZIRP ne s’était pas terminé, les LLM auraient pu fournir un argument très fort à l’ingénieur qui dit simplement « non »
- Les entreprises qui ne peuvent pas publiquement ou en interne remettre en cause le coding assisté par IA auraient fortement dépendu de ces ingénieurs pour empêcher un tsunami de code IA d’engloutir l’entreprise
- En réalité, les LLM ajoutent surtout l’insulte à la blessure existante
- Il faut désormais regarder fusionner des PR générées par IA qui auraient auparavant été bloquées, et on leur demande aussi d’utiliser eux-mêmes ces outils
- Plus gênant encore : les outils d’IA fonctionnent, globalement
- Ils ne provoquent pas encore de catastrophe manifeste, et même si le code est parfois moins propre et un peu moins compréhensible, il reste largement exploitable
- En particulier dans des entreprises qui tentent beaucoup de nouvelles choses puis abandonnent ce qui échoue, du code « suffisamment bon » passe très bien
- Même si l’on pense observer plus d’incidents récemment, on peut se tromper, ou bien d’autres facteurs liés à la fin du ZIRP — comme l’accélération du rythme ou les licenciements — peuvent être les causes principales
- L’ingénieur qui dit simplement « non » fait face à une menace non seulement sur ses moyens de subsistance, mais aussi sur son identité
- Il se retrouve à devoir accepter que son rôle technique dépendait d’un environnement économique très particulier de l’industrie tech, ou continuer d’affirmer que la fin est imminente
Pur engineering et engineering impur
- L’ingénieur qui dit simplement « non » ne va pas disparaître, mais il n’est plus aussi bien adapté à toutes les entreprises technologiques
- Dans Pure and impure software engineering, le pur engineering désigne des travaux au périmètre bien défini et aux objectifs principalement techniques, comme les compilateurs ou les runtimes de langages
- L’engineering impur désigne des travaux au périmètre flou et aux objectifs guidés par le client, comme les tentatives de nouvelles fonctionnalités dont on ne peut pas garantir le succès
- Pendant la période ZIRP, les entreprises technologiques réalisaient beaucoup plus de travaux purs, comme React), et avaient tendance à traiter même les travaux impurs comme s’ils étaient purs
- L’ingénieur qui dit simplement « non » convient très bien aux travaux purs
- Parce qu’une codebase pure exige des standards de qualité bien plus élevés et peut supporter des cycles de développement plus lents
- La plupart des entreprises technologiques continuent malgré tout d’avoir une forme de travail pur, par exemple sur l’infrastructure centrale
- Ce travail est essentiel, mais il ne nécessite pas d’immenses équipes d’ingénierie et se retrouve rarement sous les projecteurs
- Si vous voulez rester l’ingénieur qui dit simplement « non », il faut vous orienter vers ce type de rôle, tout en acceptant un périmètre plus limité qu’au cours des années 2010
Débats et perspective nuancée
- Sur lobste.rs et Reddit, certains ont critiqué l’idée qu’il serait trop tôt pour affirmer que l’impact du code IA est « globalement acceptable », car ses effets ne se verront qu’avec le temps
- Il est difficile de donner tort à l’argument du « il est encore trop tôt », mais il semble clair que le code IA n’est pas immédiatement catastrophique
- Une autre objection soulignait que l’archétype de l’ingénieur qui dit simplement « non » existait déjà depuis des décennies avant le ZIRP, avec Linus Torvalds souvent cité en exemple
- Cet archétype lui-même n’a pas été créé par le ZIRP, mais le ZIRP a artificiellement élargi la niche de ce rôle, laquelle s’est aujourd’hui à nouveau resserrée
- Une autre critique affirmait que cette niche venait plutôt de l’usage des langages dynamiques et d’outils d’observabilité et de feature flags encore immatures
- Sur Hacker News, plusieurs voix estimaient que cette théorie avait besoin de preuves plus solides
- Cette vision repose sur une fenêtre étroite d’expérience personnelle, et les généralisations sur l’industrie avant et après le ZIRP peuvent varier selon les personnes
- Pour la vérifier, on pourrait interroger des centaines d’ingénieurs seniors et plus en 2010 puis en 2026, en leur demandant combien de fois par semaine ils disaient « non » et à quelle fréquence leurs refus étaient ensuite annulés
- Dire « non » reste indispensable avant comme après le ZIRP, mais après le ZIRP la différence est que la direction a rapidement développé cette capacité elle-même, réduisant le besoin d’un groupe d’ingénieurs chargé de le dire à sa place
1 commentaires
Réactions sur Hacker News
Le code est une dette. Si un ingénieur dit « non », ce n’est pas par obsession subjective de la qualité du code, mais pour réduire la complexité
De nos jours, la direction interprète souvent mal le mot « qualité ». La qualité désigne le juste niveau d’effort nécessaire pour construire un produit aussi vite et à aussi bas coût que possible, en tenant aussi compte du fait que l’équipe d’ingénierie puisse ajouter et modifier facilement le code
Il y a une meilleure explication ici : https://www.nair.sh/guides-and-opinions/communicating-your-e...
Toute tentative de formaliser par des règles rigides ce que cette personne a fait et pourquoi est vouée à l’échec
Le problème de ce genre d’économie de comptoir, c’est qu’on peut s’en servir pour justifier les deux positions
On pourrait tout aussi bien parler de « la fin de l’ère des taux zéro et la montée de l’ingénieur qui dit simplement non ». Comme le coût du capital a augmenté, les entreprises doivent dépenser cet argent plus intelligemment, et ont donc davantage besoin du jugement d’ingénieurs capables de dire non pour éviter de le gaspiller sur l’inutile
Plus je lisais, plus je me disais : « il y a tous les termes qui sonnent bien, entre l’ère ZIRP et les ingénieurs qui disent juste non, ça donne l’impression d’être perspicace, mais dès qu’on creuse, ça ne colle pas du tout à mon expérience du terrain en ingénierie logicielle à cette époque, et ça ne diagnostique pas correctement non plus les grands changements provoqués aujourd’hui par l’IA ». Autrement dit, ça ressemblait à du bullshit à la mode, et comme il n’y a pas de bouton downvote sur l’article lui-même, je suis content que la communauté l’ait pointé
Même si un projet IA échoue, ce n’est pas grave s’il échoue assez vite pour qu’on puisse passer à autre chose. Faire les choses correctement dès le départ ne devient important que pour les projets de long terme à fort investissement initial
Dire que « la moitié des ingénieurs de l’entreprise étaient pris dans une boucle sans fin à proposer des changements et à se les voir refuser, et que c’était parfaitement acceptable. Après tout, ils n’avaient pas besoin d’être productifs, et de cette façon ils n’affectaient pas les systèmes cœur de métier » est, bon, un point de vue. Assez cynique
Avec le recul, cela sonne cynique, mais à l’époque on expliquait le même ensemble de faits d’une autre manière, moins susceptible de froisser les gens
Savoir si quelqu’un chez Facebook qui travaille sur le Metaverse fait partie des personnes clés qui prototypent de nouveaux business models, ou s’il se contente de faire semblant d’être occupé, ne devient clair qu’après coup
C’est une interprétation assez extrême. Si la fin du ZIRP a accru la concentration, la conclusion naturelle ne serait-elle pas qu’il faut refuser davantage, et non moins ?
Pour soutenir que le ZIRP a créé toutes sortes de faux boulots, puis même des couches entières chargées de contrôler ce faux travail, il faut vraiment se contorsionner
J’aime bien la distinction entre les « ingénieurs qui disent juste oui » et les « ingénieurs qui disent juste non », ainsi que l’idée de privilégier le MTTR au MTBF
Je suis clairement du côté des « juste oui », mais il faut nuancer : de mauvais choix d’architecture peuvent être très pénibles à corriger plus tard, et les fonctionnalités sont bien plus dures à modifier une fois qu’elles ont des utilisateurs qu’avant leur lancement. Donc je suis aussi un peu du côté du « juste non », ou au moins du « réfléchissons-y un instant d’abord »
L’équilibre entre « juste oui » et « juste non » dépend énormément du projet. Dans la finance ou la santé, il vaut peut-être mieux avoir « non » comme position par défaut, mais pour une idée de startup farfelue, c’est YOLO
Demander du temps pour remettre de l’ordre revient en pratique à dire non. Un responsable du développement doit avoir ce pouvoir et l’utiliser réellement. S’il ne l’utilise jamais, c’est comme s’il ne l’avait pas
Il ne faut pas devenir un ingénieur qui ne fait que dire « non » sans proposer d’alternative. Ce n’est pas un bon ingénieur, c’est quelqu’un de paresseux qui veut avoir l’air compétent
Les ingénieurs proposent souvent des solutions nécessaires mais imparfaites à cause du legacy. Et non, on ne peut pas réécrire tout le système pour le faire « correctement ». Dire « non » ou souligner qu’une solution n’est pas idéale ne fait pas de vous un génie superintelligent
En réunion avec les profils business, il se montrait intimidant parce qu’il savait coder, et le pire, c’est que lorsqu’il n’était pas d’accord avec une proposition, il ne proposait absolument aucune alternative. C’était difficile de travailler avec lui
Je me demande si la personne ZIRP décrite dans cet article, c’était lui
S’il manque encore quelque chose aux LLM et aux agents, on voit un courant qui dit qu’au lieu d’attendre des améliorations, il faut abaisser les exigences. Du genre : « concentrez-vous sur le MTTR ».
Le code est mauvais ? Ne le lisez pas, ne le relisez pas, retirez de la boucle la personne qui fait goulot d’étranglement. Ce récit se répand un peu partout.
Cette technologie est assez utile, donc j’aimerais qu’au lieu de ne traiter que les symptômes, on se concentre sur de meilleurs outils, sur de meilleures façons de travailler avec eux et sur des améliorations de processus adaptées
Il n’y a pas de fin à ce qu’on pourrait faire, mais la vraie question, c’est comment répartir le temps entre l’usage sur des projets réels et ces efforts d’amélioration
On lit que « plus il y avait d’ingénieurs, mieux c’était pour le cours de l’action… puis les banques ont relevé les taux… maintenir des organisations d’ingénierie hypertrophiées pour soutenir le cours n’était plus rentable ». Existe-t-il un mécanisme connu reliant le nombre d’ingénieurs logiciel et le cours de l’action, ou est-ce simplement un phénomène observé empiriquement ?
« Avant, il suffisait de dire non à une PR écrite à la main par un ingénieur junior, mais maintenant on se prend un flot de code généré par l’IA, dont une partie vient de managers et de VP qu’il est politiquement difficile de contredire » : mon Dieu.
J’ai travaillé dans une grande entreprise tech, mais j’ai quitté le secteur avant l’arrivée d’InstructGPT et compagnie, donc je n’ai jamais vécu la génération de code par LLM en interne. Est-ce que ça se passe vraiment comme ça ? Des cadres supérieurs et des VP proposent des modifications de code produites par LLM ? Je crois que je ne tiendrais pas
La dimension politique est bien réelle. On ne peut pas juste dire « non », et il est assez difficile de relire de manière sérieuse une PR de 25 000 lignes soumise par quelqu’un qui ne comprend pas vraiment ce qu’il fait et ne sait pas répondre aux questions
Pour être juste, il a lui-même construit une bonne partie de liquid et de Shopify au début de l’entreprise, donc ce n’est pas quelqu’un sans expérience, mais quand même
Ça ressemble à une hypothèse difficile à vérifier. Pour une entreprise qui essaie réellement d’accomplir quelque chose, est-ce qu’il n’est pas tout à fait logique d’avoir quelqu’un pour aider à prioriser en signalant quelles décisions entraînent des coûts à long terme ?