Écrire du code n’est pas difficile, la difficulté réside dans la gestion des « personnes » et de la « complexité ». Un ingénieur senior de Google partage ses 14 années d’expérience, allant de la pensée utilisateur à la collaboration en équipe, ces 21 règles d’or vous aideront à bâtir une carrière plus profonde et durable.
（Résumé précédent : La traduction instantanée de Google ouvre officiellement toutes les marques d’écouteurs : plus de 70 langues disponibles, lancement en avant-première sur les téléphones Android au Mexique et aux États-Unis）
（Complément d’information : Google lance officiellement « Gemini 3 » ! Le modèle d’IA le plus intelligent au monde, quels sont ses points forts ？）

Table des matières de cet article

• 1. Les ingénieurs de haut niveau sont obsédés par la résolution des problèmes utilisateur
• 2. « Prouver que l’on a raison » n’a aucune valeur, atteindre un objectif commun correct est l’essentiel
• 3. Privilégier l’action. Mettre en ligne ! Vous pouvez modifier une page médiocre, mais pas une page blanche
• 4. La maturité se manifeste par la clarté, l’intelligence par la charge
• 5. « La nouveauté » est un prêt à intérêt élevé emprunté à la maintenance, au recrutement et à la charge cognitive
• 6. Le code ne parlera pas pour vous, ce sont les personnes
• 7. Le meilleur code est celui que vous n’avez jamais écrit
• 8. Quand l’échelle devient grande, même vos bugs ont des utilisateurs
• 9. La plupart des équipes « lentes » sont en réalité des équipes « désalignées »
• 10. Concentrez-vous sur ce que vous pouvez contrôler, ignorez le reste
• 11. L’abstraction ne supprime pas la complexité, elle la transfère
• 12. L’écriture impose la clarté, l’enseignement est la méthode d’apprentissage la plus rapide
• 13. Rendre possibles d’autres travaux est inestimable, mais invisible
• 14. Si vous gagnez chaque débat, vous accumulez peut-être une résistance silencieuse
• 15. Quand un indicateur devient un objectif, il n’est plus un bon indicateur
• 16. Reconnaître « je ne sais pas » crée plus de sécurité que de faire semblant de comprendre
• 17. Votre contexte est plus durable que n’importe quel travail effectué
• 18. La majorité des améliorations de performance viennent de « supprimer du travail », pas d’« algorithmes intelligents »
• 19. La présence d’un processus vise à réduire l’incertitude, pas à créer de la paperasserie
• 20. Finalement, le temps vaut plus que l’argent, agissez en conséquence
• 21. Il n’y a pas de raccourcis, mais il y a l’effet composé

• Dernière réflexion

Addy Osmani, directeur de l’IA chez Google Cloud, est un ingénieur logiciel expérimenté et un penseur. Il a été responsable de l’expérience développeur chez Chrome pendant près de 14 ans, participant à des projets comme DevTools, Lighthouse et Core Web Vitals. Aujourd’hui, il coordonne le travail entre Google DeepMind, les équipes d’ingénierie, de produits et de relations avec les développeurs.

Il a publié un article approfondi sur son blog personnel pendant 3 jours. En combinant ses années d’expérience chez Google et sa professionnalisme, il a résumé 21 précieux conseils sur la communication, le choix technologique et la planification de carrière, que voici, traduit par la rédaction de Quyu :

Lorsque j’ai rejoint Google il y a environ 14 ans, je pensais que ce travail consistait à écrire du code parfait. Je ne me suis trompé que partiellement. Plus je reste, plus je réalise que les ingénieurs performants ne sont pas forcément ceux qui écrivent le plus de code, mais ceux qui ont appris à maîtriser tout ce qui dépasse le code : relations humaines, politique en entreprise, alignement des consensus et gestion de l’incertitude.

Ces expériences auraient dû m’apparaître plus tôt. Certaines m’ont évité des mois de frustration, d’autres m’ont pris des années à comprendre réellement. Rien de tout cela n’a à voir avec la technologie spécifique : la technologie évolue trop vite, ce n’est pas important. Ce qui compte, ce sont ces règles qui se répètent dans différents projets et équipes.

Je partage cela parce que j’ai beaucoup appris de ces ingénieurs qui ont voulu m’aider à progresser. C’est ma petite contribution en retour.

1. Les ingénieurs de haut niveau sont obsédés par la résolution des problèmes utilisateur

Aimer une technologie et chercher partout des cas d’usage est très séduisant. Je l’ai fait, tout le monde l’a fait. Mais le plus créateur de valeur est l’ingénieur qui fait « l’inverse » : il est obsédé par la compréhension profonde des problèmes utilisateur, et laisse que la solution naisse naturellement de cette compréhension.

L’obsession utilisateur signifie passer du temps à étudier les tickets du support, à parler avec les utilisateurs, à observer leurs difficultés, à poser sans cesse la question « pourquoi » jusqu’à toucher le cœur du problème. Les ingénieurs qui comprennent vraiment le problème découvrent souvent que la solution élégante est plus simple que prévu. Les ingénieurs qui partent de la solution ont tendance à compliquer inutilement pour justifier leur choix.

2. « Prouver que l’on a raison » n’a aucune valeur, atteindre un objectif commun correct est l’essentiel

Vous pouvez gagner chaque débat technique, mais perdre le projet entier. J’ai vu des ingénieurs intelligents accumuler du ressentiment silencieux parce qu’ils veulent toujours être la personne la plus brillante dans la salle. Ce coût se manifeste plus tard sous forme de « problèmes mystérieux d’exécution » ou de « résistances inexplicables ».

La compétence ne réside pas dans le fait d’avoir « raison », mais dans la capacité à participer à la discussion pour aligner le problème, à créer de l’espace pour les autres, et à garder un doute sur sa propre certitude. Une forte opinion, un esprit ouvert — ce n’est pas parce que vous manquez de conviction, mais parce que dans l’incertitude, vos décisions ne doivent pas être liées à votre ego.

3. Privilégier l’action. Mettre en ligne ! Vous pouvez modifier une page médiocre, mais pas une page blanche

La recherche de la perfection mène à la paralysie. J’ai vu des ingénieurs passer plusieurs semaines à discuter de l’architecture idéale d’un produit qu’ils n’ont jamais construit. La solution parfaite naît rarement d’une réflexion pure — elle naît du choc avec la réalité. L’IA peut beaucoup aider dans ce domaine.

Faites d’abord, faites juste, faites mieux. Mettez un prototype laid devant l’utilisateur. Rédigez une ébauche de document de conception chaotique. Lancez ce MVP qui vous met un peu mal à l’aise. Apprenez plus de feedbacks en une semaine qu’en un mois de débats théoriques. L’élan mène à la clarté, l’analyse paralyserait tout.

4. La maturité se manifeste par la clarté, l’intelligence par la charge

Il est presque instinctif pour un ingénieur de produire du « code intelligent », comme une preuve de sa compétence. Mais le génie logiciel est une réaction chimique entre le temps et les autres développeurs. Dans cet environnement, la clarté n’est pas une préférence stylistique, mais une réduction du risque opérationnel.

Votre code est une note stratégique pour des inconnus qui pourraient réparer à 2h du matin. Optimisez leur compréhension, pas votre élégance. Les ingénieurs seniors que je respecte le plus choisissent toujours de privilégier la « clarté » en échange de la « brillance ».

5. « La nouveauté » est un prêt à intérêt élevé emprunté à la maintenance, au recrutement et à la charge cognitive

Considérez vos choix technologiques comme une « monnaie d’innovation » dans une entreprise à budget limité. Chaque fois que vous utilisez une technologie non standard, vous dépensez une pièce. Vous ne pouvez pas vous permettre d’en dépenser beaucoup. La règle n’est pas « ne jamais innover », mais « n’innover qu’à bon escient, là où la récompense est unique ».

Tout le reste doit être considéré comme « ennuyeux », car l’ennui signifie que ses modes de défaillance sont connus. L’outil « le mieux adapté à la tâche » est souvent « l’outil qui performe le moins mal dans plusieurs tâches » — car gérer un zoo technologique devient une charge réelle.

6. Le code ne parlera pas pour vous, ce sont les personnes

Au début de ma carrière, je pensais que de bonnes performances suffisaient à tout prouver. Je me suis trompé. Le code reste silencieux dans le dépôt. La question clé est si votre manager en parle en réunion, si vos collègues vous recommandent pour un projet.

Dans une grande organisation, la décision se fait dans des réunions auxquelles vous n’êtes pas invité, par des personnes qui ont cinq minutes pour traiter douze priorités, en se basant sur un résumé que vous n’avez pas écrit. Si personne ne peut dire clairement votre impact quand vous n’êtes pas là, votre influence est insignifiante. Ce n’est pas seulement du self-promotion, c’est pour rendre la chaîne de valeur visible pour tous (y compris vous-même).

7. Le meilleur code est celui que vous n’avez jamais écrit

La culture de l’ingénierie célèbre la création. Personne ne sera promu pour avoir supprimé du code, même si supprimer optimise souvent plus que d’ajouter. Chaque ligne de code que vous n’avez pas écrite est une ligne que vous n’aurez jamais à déboguer, maintenir ou expliquer.

Avant de construire, posez-vous une question fondamentale : « Et si on ne faisait rien, qu’arriverait-il ? » Parfois la réponse est « rien de grave », et c’est votre solution. Le problème n’est pas que les ingénieurs ne savent pas coder ou utiliser l’IA, mais qu’ils sont si doués qu’ils oublient de se demander « doit-on vraiment écrire ».

8. Quand l’échelle devient grande, même vos bugs ont des utilisateurs

Quand le nombre d’utilisateurs devient suffisant, tout comportement observable devient une dépendance — peu importe ce que vous avez promis (loi de Heller). Quelqu’un exploite votre API, automatise vos fonctionnalités étranges, met en cache vos bugs.

Cela donne une insight de niveau professionnel : vous ne pouvez pas considérer la compatibilité comme de la maintenance, ni les nouvelles fonctionnalités comme du vrai travail. La compatibilité est le produit lui-même. Lors de la conception d’un plan de dépréciation, considérez-le comme une migration avec du temps, des outils et de l’empathie. La plupart des « designs d’API » sont en réalité des « retrait d’API ».

9. La plupart des équipes « lentes » sont en réalité des équipes « désalignées »

Quand un projet stagne, la première hypothèse est souvent un problème d’exécution : manque de personnel, mauvais choix technologique. Mais ce n’est généralement pas le cœur du problème. Dans une grande entreprise, l’équipe est votre unité de parallélisme, mais la coordination coûte une croissance géométrique. La majorité du ralentissement vient d’un désalignement — des gens construisent la mauvaise chose, ou construisent la bonne de façon incompatible. Les ingénieurs seniors passent plus de temps à clarifier la direction, les interfaces et les priorités qu’à « écrire plus vite du code », car c’est là le vrai goulot d’étranglement.

10. Concentrez-vous sur ce que vous pouvez contrôler, ignorez le reste

Dans une grande entreprise, d’innombrables variables échappent à votre contrôle — restructurations, décisions managériales, changements de marché, pivots produits. Se focaliser dessus ne sert qu’à générer de l’anxiété. Un ingénieur efficace et rationnel se concentre sur son cercle d’influence.

Vous ne pouvez pas contrôler une réorganisation, mais vous pouvez contrôler la qualité de votre travail, votre réaction et ce que vous apprenez. Face à l’incertitude, décomposez le problème et identifiez les actions concrètes que vous pouvez prendre. Ce n’est pas une acceptation passive, mais une stratégie ciblée. Investir de l’énergie dans ce que vous ne pouvez pas changer, c’est voler du temps à ce que vous pouvez changer.

11. L’abstraction ne supprime pas la complexité, elle la transfère

Chaque abstraction est un pari, celui de ne pas avoir à comprendre la mécanique sous-jacente. Parfois vous gagnez, mais l’abstraction finit toujours par fuir. Quand elle échoue, il faut connaître ce qui se passe en dessous. Les ingénieurs expérimentés continuent d’apprendre la « mécanique » même quand leur stack devient de plus en plus haut. Ce n’est pas par nostalgie, mais par respect pour le moment où l’abstraction échoue. Utilisez votre stack, mais maîtrisez le modèle mental de ses défaillances.

12. L’écriture impose la clarté, l’enseignement est la méthode d’apprentissage la plus rapide

Écrire force à réfléchir. Quand j’explique un concept à quelqu’un — dans un document, une présentation, une revue de code, ou même en discutant avec une IA — je découvre mes propres lacunes.

Rendre le contenu clair pour les autres le rend aussi plus clair pour moi. Ce n’est pas seulement un partage généreux de connaissances, c’est une technique d’apprentissage égoïste. Si vous pensez avoir compris quelque chose, essayez de l’expliquer simplement. Là où vous butez, c’est là où votre compréhension est superficielle. L’enseignement est un débogage de votre modèle mental.

13. Rendre possibles d’autres travaux est inestimable, mais invisible

Le « travail de glue » — documentation, onboarding, coordination inter-équipes, amélioration des processus — est crucial. Mais si vous le faites inconsciemment, cela peut freiner votre croissance technique et vous épuiser. Le piège est de le voir comme « aider les autres », alors qu’il faut le considérer comme une contribution consciente, délimitée et visible. Limitez le temps, faites-le par rotation, transformez-le en output (documents, modèles, automatisations).

Considérez cela comme une influence, pas comme une caractéristique de votre personnalité.

14. Si vous gagnez chaque débat, vous accumulez peut-être une résistance silencieuse

J’ai appris à douter de ma certitude. Quand je « gagne » trop facilement, il y a souvent quelque chose qui cloche. Les gens n’arrêtent pas de débattre parce qu’ils sont convaincus, mais parce qu’ils abandonnent la tentative — ils expriment leur opposition dans l’action, pas dans la réunion. Une vraie alignement demande plus de temps.

Il faut vraiment comprendre le point de vue des autres, intégrer leur feedback, et parfois changer d’avis publiquement. La satisfaction de gagner un débat à court terme est bien moindre que la valeur de travailler longtemps avec des partenaires sincères.

15. Quand un indicateur devient un objectif, il n’est plus un bon indicateur

Chaque indicateur que vous montrez à la direction finit par être « manipulé ». Ce n’est pas par malveillance, mais parce que l’humain optimise ce qui est mesuré (loi de Goodhart). Si vous suivez le nombre de lignes de code, vous obtiendrez plus de lignes. Si vous suivez la vitesse, vous obtiendrez une estimation gonflée.

Une pratique avancée consiste à demander deux indicateurs pour chaque métrique : un pour la vitesse, un pour la qualité ou le risque. Insistez sur l’interprétation des tendances, pas sur la fixation à un seuil. L’objectif est la compréhension, pas la surveillance.

16. Reconnaître « je ne sais pas » crée plus de sécurité que de faire semblant de comprendre

Un ingénieur senior qui dit « je ne sais pas » ne montre pas une faiblesse, mais une permission. Quand un leader admet l’incertitude, il envoie un signal : cet espace est sûr pour les autres. J’ai vu des équipes où personne n’admet ses doutes, ce qui est très dommage : personne ne pose de questions, personne ne challenge, les ingénieurs débutants restent silencieux, pensant qu’ils sont seuls à ne pas comprendre. Montrez votre curiosité, et vous aurez une équipe qui apprend vraiment.

17. Votre contexte est plus durable que n’importe quel travail effectué

Au début de ma carrière, je me concentrais sur le travail, pas sur le réseau. C’était une erreur. Investir dans ses relations (avec ses collègues, à l’intérieur comme à l’extérieur de l’entreprise) porte ses fruits sur des décennies. Ils sont les premiers à entendre parler d’opportunités, à construire des ponts plus rapidement, à recommander pour des postes, à co-fonder avec des personnes de confiance. Le travail n’est pas éternel, mais le réseau l’est. Construisez des relations avec curiosité et générosité, pas par transaction.

18. La majorité des gains de performance viennent de « supprimer du travail », pas d’« algorithmes intelligents »

Quand un système devient lent, la réaction instinctive est d’ajouter : cache, parallélisme, algorithmes plus intelligents. Parfois c’est vrai, mais j’ai vu plus souvent des gains en se posant la question : « Qu’est-ce qu’on calcule qui n’a pas besoin d’être calculé ? » La suppression de travail inutile est presque toujours plus efficace que d’accélérer le travail nécessaire. Le code le plus rapide est celui qui ne tourne jamais.

19. La présence d’un processus vise à réduire l’incertitude, pas à créer de la paperasserie

Les meilleurs processus facilitent la coordination, réduisent le coût d’échec. Les pires sont la « bureacratie dramatique » — leur existence n’est pas pour aider, mais pour décharger en cas de problème. Si vous ne pouvez pas expliquer comment un processus réduit le risque ou augmente la clarté, il est probablement un fardeau. Si les gens passent plus de temps à documenter qu’à faire, c’est un gros problème.

20. Finalement, le temps vaut plus que l’argent, agissez en conséquence

Au début de ma carrière, j’échangeais du temps contre de l’argent, ce qui est normal. Mais à un moment, cette logique s’inverse. Le temps devient une ressource non renouvelable. J’ai vu des ingénieurs expérimentés épuisés à poursuivre un grade ou à optimiser quelques points de salaire. Certains y parviennent, mais la majorité se demande après si cela en valait la peine. La réponse n’est pas « ne pas travailler dur », mais « savoir ce que vous échangez, et le faire consciemment ».

21. Il n’y a pas de raccourcis, mais il y a l’effet composé

Le savoir-faire vient de la pratique délibérée — dépasser légèrement ses compétences actuelles, réfléchir, répéter, continuer pendant des années. Il n’y a pas de version abrégée. Mais l’espoir est que : lorsque l’apprentissage crée de nouvelles options plutôt que de simples connaissances dispersées, il produit des intérêts composés. Écrire (pour la clarté), construire des composants réutilisables, collecter ses leçons douloureuses dans un manuel. Les ingénieurs qui voient leur carrière comme un « intérêt composé » plutôt qu’un « loto » avancent beaucoup plus loin.

Dernière réflexion

Ces 21 règles peuvent sembler beaucoup, mais leur cœur tourne autour de quelques idées fondamentales : reste curieux, reste humble, et souviens-toi que le travail concerne toujours les personnes — y compris les utilisateurs pour lesquels tu construis, et tes collègues avec qui tu construis.

La carrière d’ingénieur est longue, suffisamment pour faire beaucoup d’erreurs et continuer à réussir. Les ingénieurs que j’admire le plus ne sont pas ceux qui ne font jamais d’erreurs, mais ceux qui apprennent de leurs erreurs, partagent leurs découvertes, et persévèrent.

Si tu débutes cette aventure, sache qu’elle deviendra de plus en plus passionnante avec le temps. Si tu es déjà expérimenté, j’espère que quelques-unes de ces règles résonneront en toi.