14 autres leçons tirées de 14 années chez Google

1. Les meilleurs ingénieurs choisissent les bons problèmes

On ne peut pas consacrer un maximum d’énergie à tout.

2. Si vous ne savez pas ce que vous devez demander, c’est que vous n’êtes pas prêt pour la réunion

Autorisation, choix, levée de blocage (unblock), partage d’information (inform) — si vous ne pouvez pas en choisir un, cette réunion sera une perte de temps.

3. « Il faut le faire » n’est pas un plan. « Je le ferai mardi » est un plan.

Fixer une date précise crée de l’élan.

4. Un code lent n’est qu’un symptôme ; la vraie cause, ce sont les décisions lentes.

S’il faut des semaines, et non des heures, pour décider de quelque chose, il faut examiner pourquoi.

5. Considérez la fiabilité (Reliability) comme une fonctionnalité du produit

De même qu’on ne livre pas une fonctionnalité sans revue du produit, on ne devrait pas déployer un système sans discussion sur sa fiabilité.

6. Si l’interface entre les équipes est mauvaise, la communication ne peut pas bien fonctionner

Des frontières floues et des contrats (Contract) peu clairs créent davantage de réunions et de canaux Slack. Il faut savoir clairement qui est responsable de quoi et comment chacun dépend des autres.

7. La meilleure escalade est celle qui s’accompagne d’une proposition.

Celui qui signale le problème comme celui qui le résout ont tous deux compris l’enjeu, mais un seul des deux gagne la confiance et l’autonomie.

8. Construisez des systèmes qui n’ont pas besoin de héros

Si une seule personne est constamment en train de sauver l’entreprise ou l’équipe, ce n’est pas glorieux : c’est le signe que tout est en train de s’effondrer.

9. Traitez l’observabilité (Observability) comme une partie de la fonctionnalité

Considérez que le travail n’est terminé que lorsque vous avez confirmé que le code fonctionne correctement.

10. Les petites PR sont une forme de bienveillance. Surtout si elles ont été générées par une IA.

Les petites PR permettent de raisonner de façon incrémentale et d’accumuler les connaissances petit à petit.

11. Ajouter une nouvelle équipe, ce n’est pas seulement ajouter des nœuds (Node), c’est aussi ajouter des arêtes (Edge)

Si l’on ne réduit pas volontairement les connexions, ajouter une nouvelle équipe ne change pas le niveau d’output.

12. Une migration n’est jamais juste une migration

Les migrations qui se terminent réellement ont trois points communs : un sponsor impliqué dans la durée, une équipe qui porte réellement la migration, et une date de fin claire en laquelle tout le monde a confiance. Si ces trois conditions ne sont pas réunies, la migration reste éternellement dans un état de « presque terminé », et l’on continue indéfiniment à porter deux systèmes.

13. L’IA facilite la production de brouillons, et le goût (Taste) devient de plus en plus rare.

Les ingénieurs capables de sélectionner ce qu’il y a de meilleur seront les meilleurs de cette époque.

14. La confiance est une optimisation de la latence

Chaque fois que vous tenez une promesse, que vous reconnaissez honnêtement une erreur, ou que vous facilitez la vie des autres, vous faites un dépôt. J’ai vu des ingénieurs au niveau technique ordinaire obtenir des résultats extraordinaires simplement parce que tout le monde leur faisait confiance.

---

Ceci est la suite de https://fr.news.hada.io/topic?id=24909.

[mhj5730]

Je recommande de lire le texte original.
Il contient beaucoup d’expressions et de formulations pleines de perspicacité, qui donnent souvent envie de réfléchir à partir de sa propre expérience.

Le contenu est long et peut sembler dense, mais ce sont vraiment d’excellents écrits, au point qu’on a l’impression qu’il n’y a rien à retirer ni rien de superflu à élaguer ici.

[raykim]

Je connaissais les points 5 et 9, mais ce sont des choses faciles à manquer
Les points 12, 13 et 14 sont impressionnants