21 leçons tirées de 14 ans chez Google
(addyo.substack.com)- Les ingénieurs d’exception ne sont pas les meilleurs programmeurs, mais ceux qui ont appris à naviguer entre les personnes autour du code, la politique, la coordination et l’ambiguïté
- Le propos se concentre moins sur la technologie que sur les schémas récurrents dans les projets et les équipes, en couvrant la résolution des problèmes utilisateurs, la collaboration d’équipe, la qualité du code et la gestion de carrière
- Il montre que la clarté est la qualité centrale d’un ingénieur senior, et que l’ingéniosité n’est souvent qu’un surcoût, avec cette intuition paradoxale que le meilleur code est parfois celui qu’on n’écrit pas
- Dans les grandes organisations, les défauts d’alignement sont une cause majeure de ralentissement, et dès qu’un indicateur devient un objectif, il se déforme : un piège classique du fonctionnement organisationnel
- À long terme, le temps devient une ressource plus précieuse que l’argent, et comme le réseau dure plus longtemps que n’importe quel poste, il faut concevoir sa carrière de manière intentionnelle
1. Les meilleurs ingénieurs sont obsédés par la résolution des problèmes utilisateurs
- Il est tentant de tomber d’abord amoureux d’une technologie puis de lui chercher un usage, mais les ingénieurs qui créent le plus de valeur travaillent à l’envers : ils comprennent en profondeur le problème de l’utilisateur et en déduisent la solution
- L’obsession de l’utilisateur, c’est consacrer du temps aux tickets de support, parler aux utilisateurs, observer leurs difficultés et continuer à demander « pourquoi » jusqu’à atteindre la cause profonde
- Les ingénieurs qui comprennent vraiment le problème découvrent que les solutions élégantes sont souvent plus simples qu’ils ne l’imaginaient
- Ceux qui partent de la solution ont tendance à construire de la complexité pour la justifier
2. Avoir raison est facile ; parvenir ensemble à ce qui est juste, voilà le vrai travail
- On peut gagner tous les débats techniques et perdre quand même le projet ; il a vu des ingénieurs brillants toujours être les plus intelligents dans la pièce tout en accumulant une rancœur silencieuse
- Le coût apparaît plus tard sous forme de « problèmes d’exécution mystérieux » et de « résistances étranges »
- La compétence clé n’est pas d’avoir raison, mais de participer aux discussions pour aligner le problème, faire de la place aux autres et rester sceptique vis-à-vis de ses propres certitudes
- Des opinions fortes, mais un attachement faible : non parce qu’il manquerait de conviction, mais parce qu’il ne faut pas lier son identité à des décisions prises dans l’incertitude
3. Lancez avec un biais pour l’action. Une mauvaise page se modifie ; une page vide, non
- La quête de perfection paralyse ; il a vu des ingénieurs passer des semaines à débattre de l’architecture idéale de choses qu’ils n’avaient jamais construites
- La solution parfaite n’émerge pas de la seule réflexion, mais du contact avec le réel, et l’IA peut aider de multiples façons
- Faire d’abord, bien faire ensuite, puis faire mieux : mettre un prototype bancal devant les utilisateurs, rédiger une première version désordonnée d’un design doc, lancer un MVP un peu embarrassant
- Une semaine de feedback réel apprend plus qu’un mois de débats théoriques ; l’élan crée de la clarté, alors que la paralysie d’analyse ne produit rien
4. La clarté est la marque des seniors ; l’ingéniosité est un surcoût
- L’envie d’écrire du code astucieux est presque universelle chez les ingénieurs et donne l’impression de prouver sa compétence
- Le software engineering commence vraiment quand on ajoute du temps et d’autres programmeurs ; dans cet environnement, la clarté n’est pas une préférence de style, mais une réduction du risque opérationnel
- Le code est une note stratégique destinée à des inconnus qui le maintiendront à 2 h du matin pendant un incident ; il faut donc optimiser non pas l’élégance, mais leur compréhension
- Les ingénieurs seniors les plus respectés apprennent à échanger l’ingéniosité contre la clarté, à chaque fois
5. La nouveauté est une dette que l’on paie en incidents, en recrutement et en charge cognitive
- Il faut traiter les choix technologiques comme si l’organisation disposait d’un petit budget de « jetons d’innovation », dont on dépense un à chaque adoption vraiment non standard ; on ne peut pas en absorber beaucoup
- L’idée n’est pas « n’innovez jamais », mais « n’innovez que là où l’on vous récompense pour innover de façon unique » ; pour le reste, le défaut devrait être l’ennui
- L’ennui a des modes de défaillance connus
- Le « meilleur outil pour le job » signifie souvent « l’outil le moins mauvais sur beaucoup de jobs », parce qu’exploiter un zoo d’outils a un coût bien réel
6. Le code ne plaide pas pour vous ; les gens, si
- Au début de sa carrière, il croyait qu’un excellent travail parlerait de lui-même, mais c’était une erreur : le code reste simplement assis en silence dans le dépôt
- Un manager vous cite ou non en réunion, un collègue vous recommande ou recommande quelqu’un d’autre sur un projet
- Dans les grandes organisations, les décisions se prennent dans des réunions auxquelles vous n’êtes pas invité, à partir de résumés que vous n’avez pas écrits, par des gens qui ont 5 minutes et 12 priorités
- Si personne ne peut exprimer votre impact dans une pièce où vous n’êtes pas, alors cet impact devient en pratique optionnel ; il ne s’agit pas d’auto-promotion, mais de rendre la chaîne de valeur lisible pour tout le monde, vous compris
7. Le meilleur code est celui qu’il n’a jamais fallu écrire
- La culture de l’ingénierie célèbre la création, mais supprimer du code améliore souvent davantage un système qu’en ajouter, et pourtant personne n’est promu pour avoir supprimé du code
- Chaque ligne de code non écrite est une ligne qu’il n’a pas fallu déboguer, maintenir ni expliquer
- Il faut épuiser les questions avant de construire : « Et si on ne le faisait tout simplement pas ? » Parfois, la réponse est « rien de grave », et c’est alors la solution
- Le problème n’est pas que les ingénieurs ne savent pas écrire du code ou ne peuvent pas en écrire avec l’IA, mais qu’ils savent trop bien le faire et oublient de demander s’il faut vraiment l’écrire
8. À grande échelle, même les bugs ont des utilisateurs
- Avec assez d’utilisateurs, tout comportement observable devient une dépendance, indépendamment de ce qui était promis : quelqu’un scrape l’API, automatise une bizarrerie, ou met un bug en cache
- Cela mène à une intuition de niveau carrière : on ne peut pas traiter le travail de compatibilité comme de la « maintenance » et les nouvelles fonctionnalités comme le « vrai travail » ; la compatibilité, c’est le produit
- Il faut concevoir les suppressions de support comme des migrations, avec du temps, des outils et de l’empathie
- La plupart du « design d’API » est en réalité une question de « retraite d’API »
9. La plupart des équipes « lentes » sont en réalité des équipes désalignées
- Quand un projet dérape, l’instinct est d’accuser l’exécution : les gens ne travaillent pas assez dur, la technologie est mauvaise, il n’y a pas assez d’ingénieurs ; mais ce n’est généralement pas le vrai problème
- Dans les grandes entreprises, l’équipe est l’unité de concurrence, mais plus les équipes se multiplient, plus le coût de coordination augmente de façon exponentielle
- La plupart des lenteurs sont en fait des échecs d’alignement : on construit la mauvaise chose, ou la bonne chose d’une manière incompatible
- Les ingénieurs seniors passent plus de temps à clarifier la direction, les interfaces et les priorités qu’à « écrire du code plus vite », parce que c’est là que se situe le vrai goulot d’étranglement
10. Concentrez-vous sur ce que vous pouvez contrôler, ignorez le reste
- Dans les grandes entreprises, d’innombrables variables échappent à votre contrôle — réorganisations, décisions managériales, évolutions du marché, pivots produit — et s’y accrocher crée une anxiété sans capacité d’action
- Les ingénieurs qui restent efficaces et gardent leur santé mentale se concentrent sur leur sphère d’influence : on ne contrôle pas une réorganisation, mais on contrôle la qualité de son travail, sa manière de réagir et ce qu’on apprend
- Face à l’incertitude, il faut découper le problème et identifier les actions concrètes qui vous sont accessibles
- Ce n’est pas de l’acceptation passive, mais une concentration stratégique : l’énergie dépensée sur ce qu’on ne peut pas changer est une énergie volée à ce qu’on peut changer
11. L’abstraction ne supprime pas la complexité ; elle la déplace au moment où vous êtes d’astreinte
- Toute abstraction est un pari selon lequel vous n’aurez pas besoin de comprendre ce qu’il y a dessous, et parfois ce pari réussit
- Mais quelque chose finit toujours par fuir, et quand cela arrive, il faut savoir sur quoi l’on est en train de se tenir
- Plus la stack monte, plus les ingénieurs seniors continuent d’apprendre les couches « bas niveau » — non par nostalgie, mais par respect pour ces moments où les abstractions échouent et où l’on se retrouve seul avec le système à 3 h du matin
- Utilisez la stack, mais gardez un modèle opérationnel de ses modes de défaillance fondamentaux
12. Écrire force la clarté. Et la façon la plus rapide de mieux apprendre quelque chose est d’essayer de l’enseigner
- Écrire force la clarté : lorsqu’on explique un concept à quelqu’un d’autre — dans une documentation, une présentation, un commentaire de code review, ou même en discutant avec une IA — on découvre les trous dans sa propre compréhension
- Le fait de rendre quelque chose lisible pour les autres le rend aussi plus lisible pour soi-même
- Cela ne veut pas dire qu’on apprend à devenir chirurgien en l’enseignant, mais cette idée est globalement vraie dans le domaine du software engineering
- Ce n’est pas seulement une générosité de partage de connaissance ; c’est aussi un hack d’apprentissage égoïste : si vous pensez comprendre quelque chose, essayez de l’expliquer simplement ; l’endroit où vous bloquez révèle la faiblesse de votre compréhension
- Enseigner, c’est déboguer son propre modèle mental
13. Le travail qui rend possible le travail des autres est précieux, mais invisible
- Le travail de glue — documentation, onboarding, coordination inter-équipes, amélioration des processus — est indispensable, mais s’il est pris en charge sans conscience, il peut figer votre trajectoire technique et mener au burn-out
- Le piège consiste à le faire parce que c’est « utile », au lieu de le traiter comme quelque chose de délibéré, borné et à impact visible
- Il faut le limiter dans le temps, le faire tourner et le transformer en livrables : documents, templates, automatisations — puis rendre cela lisible comme un impact, et non comme un trait de personnalité
- Ce qui est précieux mais invisible est une combinaison dangereuse pour une carrière
14. Si vous gagnez tous les débats, vous êtes probablement en train d’accumuler de la résistance silencieuse
- Il a appris à douter de ses propres certitudes ; quand il est trop facile de « gagner », c’est généralement qu’il y a quelque chose qui cloche
- Si les gens arrêtent de vous contredire, ce n’est pas forcément parce que vous les avez convaincus, mais parce qu’ils ont renoncé ; et ils exprimeront ce désaccord dans l’exécution plutôt qu’en réunion
- Le véritable alignement prend plus de temps : il faut réellement comprendre les autres points de vue, intégrer les retours et parfois changer d’avis publiquement
- La satisfaction à court terme d’avoir raison vaut bien moins que la réalité de long terme qui consiste à construire quelque chose avec des collègues prêts à coopérer
15. Quand une mesure devient un objectif, elle cesse d’être une bonne mesure
- Tout indicateur exposé au management finit par être manipulé, non par malveillance, mais parce que les humains optimisent ce qui est mesuré
- Si l’on suit les lignes de code, on obtient plus de lignes ; si l’on suit la vélocité, on obtient des estimations gonflées
- Le réflexe senior consiste à répondre à toute demande d’indicateur par une paire : un pour la vitesse, un pour la qualité ou le risque ; puis à défendre l’interprétation des tendances plutôt que le culte des seuils
- L’objectif est la compréhension, pas la surveillance
16. Admettre ce qu’on ne sait pas crée plus de sécurité que faire semblant de savoir
- Un ingénieur senior qui dit « je ne sais pas » ne montre pas une faiblesse ; il donne l’autorisation aux autres d’en faire autant
- Quand un leader reconnaît l’incertitude, il signale aux autres qu’ils peuvent faire de même ; sinon, on crée une culture où tout le monde fait semblant de comprendre jusqu’à ce que le problème explose
- Il a vu des équipes où la personne la plus senior n’admettait jamais sa confusion, avec tous les dégâts qui s’ensuivent : les questions ne sortent pas, les hypothèses ne sont pas remises en cause, et les juniors se taisent parce qu’ils supposent que tout le monde a compris
- Si l’on donne l’exemple de la curiosité, on obtient une équipe qui apprend réellement
17. Votre réseau durera plus longtemps que n’importe quel poste que vous occuperez
- Au début de sa carrière, il s’est concentré sur le travail et a négligé le networking ; avec le recul, c’était une erreur
- Les collègues qui ont investi dans leurs relations — dans l’entreprise comme en dehors — en ont tiré des bénéfices pendant des décennies
- Ils entendaient parler des opportunités en premier, construisaient des passerelles plus vite, étaient recommandés pour des rôles, et cofondaient des ventures avec des personnes avec qui ils avaient bâti de la confiance au fil des années
- Un emploi ne dure pas éternellement, mais le réseau dure plus longtemps que chacun de ces emplois ; il faut l’aborder avec curiosité et générosité, pas comme une agitation transactionnelle
- Quand vient le moment de partir, ce sont souvent les relations qui ouvrent les portes
18. La plupart des gains de performance viennent de la suppression de travail, pas de l’ajout d’ingéniosité
- Quand un système ralentit, l’instinct est d’ajouter quelque chose — une couche de cache, du parallélisme, un algorithme plus intelligent — et parfois c’est la bonne réponse ; mais il a vu bien plus de gains en demandant : « Qu’est-ce qu’on peut éviter de calculer ? »
- Supprimer du travail inutile a presque toujours plus d’impact que rendre plus rapide le travail nécessaire ; le code le plus rapide est celui qui ne s’exécute pas
- Avant d’optimiser, il faut se demander si ce travail doit exister
19. Un processus existe pour réduire l’incertitude, pas pour produire une trace papier
- Les meilleurs processus rendent la coordination plus facile et l’échec moins coûteux ; les pires ne sont qu’un théâtre bureaucratique — ils ne servent pas à aider, mais à attribuer les torts quand quelque chose tourne mal
- Si l’on ne peut pas expliquer comment un processus réduit le risque ou augmente la clarté, alors c’est probablement juste du surcoût
- Si les gens passent plus de temps à documenter le travail qu’à faire le travail, c’est que quelque chose ne tourne vraiment pas rond
20. Avec le temps, le temps devient plus précieux que l’argent ; agissez en conséquence
- Au début d’une carrière, on échange son temps contre de l’argent, et c’est normal ; mais à un certain moment, le calcul s’inverse : on comprend que le temps est une ressource non renouvelable
- Il a vu des ingénieurs seniors s’épuiser à poursuivre le niveau de promotion suivant ou à optimiser quelques points de pourcentage de rémunération supplémentaires
- Certains ont obtenu ce qu’ils voulaient, mais la plupart ont fini par se demander plus tard si ce à quoi ils avaient renoncé en valait vraiment la peine
- La réponse n’est pas « ne travaillez pas dur », mais « sachez ce que vous échangez, et faites-le de manière intentionnelle »
21. Il n’y a pas de raccourci, mais il y a l’effet cumulatif
- L’expertise vient de la pratique délibérée : se pousser juste au-delà de ses compétences actuelles, réfléchir, répéter — pendant des années — ; il n’existe pas de version compressée
- La partie encourageante, c’est que l’apprentissage produit un effet cumulatif lorsqu’il crée de nouvelles options, et pas seulement de nouveaux petits savoirs
- Il faut écrire — non pour l’engagement, mais pour la clarté —, construire des briques réutilisables et transformer les cicatrices en playbooks
- Les ingénieurs qui traitent leur carrière comme des intérêts composés ont tendance à aller bien plus loin que ceux qui la traitent comme un billet de loterie
Réflexion finale
- Ces 21 leçons peuvent sembler nombreuses, mais elles se ramènent en réalité à quelques idées centrales : rester curieux, rester humble, et comprendre que le travail concerne toujours des personnes — les utilisateurs pour lesquels on construit, et les coéquipiers avec qui on construit
- Une carrière d’ingénieur est assez longue pour faire beaucoup d’erreurs tout en continuant d’avancer, et les ingénieurs qu’il respecte le plus ne sont pas ceux qui ont tout bien fait, mais ceux qui ont appris de ce qui n’allait pas, partagé ce qu’ils avaient découvert et continué à être présents
- Si vous êtes au début du voyage, sachez que tout cela s’enrichit avec le temps ; et si vous avez déjà de la profondeur, il espère qu’une partie de tout cela fera écho chez vous
5 commentaires
Commentaires Hacker News
Cela m’a rappelé la phrase : « à grande échelle, même les bugs ont des utilisateurs »
Dans mon premier job, j’avais réduit le temps de chargement de 5 minutes à 30 secondes, et des clients s’en étaient plaints
C’est parce qu’ils n’avaient plus le temps de laisser l’ordinateur tourner, d’aller prendre un café et de bavarder
La leçon de cette histoire n’est pas simplement qu’il ne faut pas améliorer les choses, mais qu’il ne faut jamais oublier que le logiciel existe dans les habitudes et les interactions de vraies personnes
Le travail d’un ingénieur n’est pas de traiter des tickets, mais de résoudre de vrais problèmes utilisateurs
Plus on augmentait l’efficacité, plus les employés devaient fournir de travail physique, ce qui a fini par créer du mécontentement
Au final, j’avais l’air d’être « celui qui avait cassé un bon système »
Il y a cette phrase : « Avec un nombre suffisant d’utilisateurs, tout comportement observable d’un système finit par devenir une dépendance pour quelqu’un »
À chaque fois, je me disais « cette fois ils vont le corriger », mais comme ce n’a pas été corrigé pendant 10 ans, cela a paradoxalement permis à mon entreprise de tenir
Les trois parties comprennent le problème différemment
Le sens du code ne change ni par l’intention ni par l’espoir, et il ne fonctionne qu’à l’intérieur des contraintes du monde réel
Article lié : Laws of Software Evolution
Mais toutes les entreprises ne le voient pas ainsi
Il est important de clarifier les attentes lors de l’entretien
En lisant ce texte écrit par Addy Osmani, j’ai ressenti une certaine hypocrisie
Il avait plagié mon code autrefois, puis a publié plus tard des excuses, sans les partager sur les réseaux sociaux
Si les excuses étaient sincères, je pense qu’il aurait aussi dû les rendre publiques auprès de ses abonnés
Les trois premières leçons m’ont particulièrement parlé
Le problème, c’est qu’on apprend les langages et les frameworks dans les cursus, mais pas les problèmes eux-mêmes
Le consensus se construit dans le processus créatif, et le pouvoir ne devrait être utilisé qu’en temps de crise
On perd souvent du temps à débattre par peur d’échouer
C’est dans l’essai « Boring Technology » que j’ai découvert pour la première fois le concept de « jetons d’innovation »
C’est un texte de boringtechnology.club, et cela reste l’un de mes articles préférés sur l’architecture
La phrase « les abstractions ne suppriment pas la complexité, elles la déplacent simplement au moment où vous êtes d’astreinte » m’a rappelé la Law of Leaky Abstractions de Joel Spolsky
Après 15 ans de leadership, j’ai exploité des systèmes de plusieurs milliards de dollars dans une grande entreprise de retail
Mais au final, ce qui comptait vraiment, c’était la politique et les relations humaines
Même des gens plus brillants n’ont pas été promus faute de savoir jouer le jeu politique
J’en suis arrivé à l’amère conclusion qu’il faudrait apprendre à ses enfants « la politique et la flatterie »
Je me reconnais profondément dans l’idée que « Clarity is seniority »
La clarté est au cœur de la maintenabilité et de la scalabilité
J’ai écrit le livre Elements of Code pour enseigner cela
L’abstraction n’est pas mauvaise en soi ; le vrai problème, c’est la clarté de l’objectif
C’est comme un ingénieur civil qui construirait un pont dans un entrepôt sans regarder le terrain
Il ne faut pas blâmer l’abstraction elle-même, mais comprendre ce qu’on essaie de modéliser
Une mauvaise abstraction nuit à la clarté et produit une complexité inutile
Je préfère encore une abstraction insuffisante
La vraie valeur de ce type de liste, c’est de l’écrire soi-même
Se contenter de lire ne laisse vite plus grand-chose, alors que réfléchir à sa propre carrière et mettre ses idées à plat donne du sens
Ce texte n’exprime pas les valeurs officielles de Google, mais des leçons personnelles apprises en travaillant chez Google
Ce n’est pas quelque chose que l’organisation a enseigné, mais des prises de conscience tirées de l’expérience
Le point important, c’est que même dans une grande entreprise, ce sont encore des sujets difficiles
« À grande échelle, même les bugs ont des utilisateurs », c’est proche du phénomène d’ossification
Cela ne s’applique pas seulement aux protocoles réseau, mais à tous les systèmes
La conception chiffrée de HTTP/3 et QUIC vise aussi à empêcher les équipements intermédiaires de faire de mauvaises hypothèses
De la même manière, une API ne devrait pas exposer son état interne
La formule « Bias towards action » m’a marqué
Même les meilleurs conseils ne servent à rien face à une page blanche
Il faut d’abord construire quelque chose pour pouvoir obtenir des retours
Dès qu’on tape la première lettre, des problèmes inattendus apparaissent
Plus une organisation est grande, plus il y a de goulots d’étranglement invisibles de ce genre
« Ship fast » ne veut pas dire « livrer quelque chose de bâclé »
Je pense qu’un produit minimal mais soigné vaut mieux
L’écart entre l’idéal et la réalité est énorme, et l’auteur le tourne en dérision en disant que « le Kool Aid était bon »
Sinon, cela est perçu comme du travail bâclé, et au moindre problème, on devient le bouc émissaire
C’est un bon article. C’était l’occasion de me rappeler que la progression de carrière inclut aussi une maturation personnelle. Merci pour cette lecture.
Ce ne sont que des paroles très justes.
La première leçon est déjà tellement importante.
C’est exactement ce que je ressens très fortement en ce moment haha
Il y avait tellement de bons passages, et tant de phrases pleines de discernement, que cela m’a arraché une exclamation d’admiration. J’ai aussi beaucoup apprécié que les phrases principales soient mises en gras.
"Avoir raison sur le moment vaut bien moins que la réalité à long terme de construire quelque chose avec des collègues prêts à coopérer."
"Il faut faire preuve de concentration stratégique, et l’énergie dépensée sur ce qu’on ne peut pas changer est une énergie volée à ce qu’on peut changer."
Il y avait aussi beaucoup d’idées utiles à appliquer non seulement au travail, mais aussi à la vie. Merci pour ce très bon article.
"Le code est une note stratégique destinée à des inconnus qui en assureront la maintenance à 2 heures du matin pendant une panne ; il doit donc optimiser la compréhensibilité."
"L’élan crée de la clarté, tandis que la paralysie de l’analyse ne produit rien."