Coder chez Google - Management

Ce billet fait partie d'une série en 4 volets : #1, #2, #3, #4.

Voici une sélection (arbitraire) de citations et de notes sur le livre Software engineering at Google.

Le bouquin est un pavé. C'est assez ironique quand on y trouve au beau milieu une citation attribuée à Blaise Pascal :

If I had more time, I would have written you a shorter letter.

Je pense qu'ils n'ont pas eu assez de temps pour raccourcir le bouquin ;)

Quoi qu'il en soit, cette partie rassemble mes notes sur le management.

Qu'est-ce que l'ingénierie logicielle ?

Chap. 1 What is software engineering?

L'ingénierie logicielle est la programmation intégrée dans le temps :

Software engineering is programming integrated over time (maintaining over time).

Ce chapitre met l'accent sur le contraste entre une vision de la programmation en tant que production de code qui répond rapidement à un problème versus l'ingénierie logicielle vue comme une pratique plus large avec des outils, des politiques et des processus visant à répondre à un problème dynamique et ambigu pouvant s'étendre sur des décennies ou même sur toute une vie.

Certains manageurs considèrent le travail des développeurs comme du "développement logiciel" (s'asseoir et écrire du code) plutôt que du "génie logiciel" (produire du code, le maintenir en état de marche et pouvoir le faire évoluer facilement pendant longtemps).

La base de code de votre organisation est durable lorsque vous êtes en mesure de faire tous les changements que vous devez faire, en toute sécurité, et que vous pouvez le faire pendant toute la durée de vie de votre base de code.

Il y a une différence fondamentale entre "le programme marche" et "le programme est correct", voir Hyrum's Law, An observation on Software Engineering :

"Can I assume a particular output sequence for my hash container?"

For a short-lived program depending on the iteration order [that] will not cause any technical problems.

[but] For a software engineering project such reliance on a defined order is a risk.

Comment bien travailler en équipe ?

Chap. 2 How to work well on teams

Le développement de logiciels est un travail d'équipe or les gens sont intrinsèquement imparfaits.

Pour construire une bonne équipe, vous devez adapter vos comportements autour de trois piliers essentiels des aptitudes sociales :

• Humilité : vous êtes ouvert à l'amélioration personnelle
• Respect : vous traitez les autres avec gentillesse et appréciez leurs capacités et leurs réalisations
• Confiance : vous pensez que les autres sont compétents et prendront les bonnes décisions

Si vous effectuez une analyse des causes de presque tous les conflits sociaux, vous pouvez remonter à un manque d'humilité, de respect et/ou de confiance.

Ce qui a le potentiel de faire votre carrière est la qualité de votre collaboration avec les autres.

Le mythe du génie est la tendance selon laquelle, en tant qu'êtres humains, nous attribuons le succès d'une équipe à une seule personne. Vous n'êtes probablement pas un génie.

Les gens ont parfois peur que les autres voient et jugent leur travail en cours. Cette insécurité est le symptôme d'un problème plus vaste. La dissimulation est considérée nocive : si vous gardez votre code caché jusqu'à sa publication, vous prenez un énorme risque. Il est facile de faire des erreurs de conception fondamentales dès le début. Vous risquez de réinventer la roue. Rendez public votre travail en cours.

L'absence de partage d'informations augmente le facteur d'autobus (the bus factor) : le nombre de personnes qui doivent se faire renverser par un autobus avant que votre projet ne soit complètement condamné.

Vous n'êtes pas votre code. Répétez-le encore et encore. Vous devez non seulement y croire vous-même, mais aussi faire en sorte que votre équipe en soit convaincue.

Votre culture de post-mortem doit être irréprochable : la clé pour tirer les leçons de vos erreurs est de documenter vos échecs dans un rapport de post-mortem en effectuant une analyse des causes profondes sans blâmer des personnes en particulier.

Un bon post-mortem doit comprendre :

• Un bref résumé de l'événement
• Une chronologie de l'événement, de la découverte à la résolution en passant par l'investigation
• La cause de l'événement
• Une évaluation de l'impact et des dommages
• Une série d'actions (avec les gens en charge) pour résoudre le problème immédiatement
• Une série d'actions pour éviter que l'événement ne se reproduise
• Les leçons tirées

Partage des connaissances

Chap. 3 Knowledge sharing

Le grossissement d'une équipe est linéaire, mais le coût de la communication au sein de l'équipe est exponentiel, voir The Mythical Man-Month: Essays on Software Engineering.

Les défis qui se posent lors du grossissement d'une organisation :

• Les gens ont peur de prendre des risques parce qu'ils craignent d'être punis
• Les connaissances sont fragmentées dans les différentes parties d'une organisation
• Il y a un point de défaillance unique (SPOF) lorsque les informations critiques ne sont disponibles que pour une seule personne
• Mimétisme sans compréhension : copier des modèles ou du code sans en comprendre le but
• Cimetières hantés : des endroits dans le code que les gens évitent de toucher de peur que quelque chose ne tourne mal

Une part énorme de l'apprentissage consiste à pouvoir essayer des choses et à se sentir en sécurité en cas d'échec. La sécurité psychologique est la partie la plus importante d'une équipe efficace. Évitez d'être accidentellement condescendant ou inamical, voir les social rules du Recurse Center.

Approfondissez vos connaissances et demandez de l'aide quand vous êtes bloqué. La patience et la gentillesse dans les réponses aux questions favorisent un environnement dans lequel les gens se sentent en sécurité lorsqu'ils cherchent de l'aide.

Comprenez le contexte : avant de supprimer ou de changer quelque chose, il faut d'abord comprendre pourquoi c'est là, voir Chesterton's fence :

Don't change something until you understand why it is the way it is. There may be a valid reason for it to be that way.

Commencez petit : quand vous apprenez quelque chose, écrivez-le. Google utilise YAQS (Yet another question system), un genre de Stack Overflow interne.

La documentation est importante. Au niveau méta, le code représente de la connaissance, de sorte que l'acte même d'écrire du code peut être considéré comme une forme de transcription de la connaissance. Par conséquent, la lisibilité du code est primordiale. Elle permettra d'accroître la productivité au fil du temps.

Le code est lu bien plus souvent qu'il n'est écrit. Chaque modification de code nécessite une approbation de la lisibilité dans la revue de code. Chez Google, ça veut dire qu'une personne ayant une certification de lisibilité pour ce langage doit approuver la modification. Toute personne dont le code bénéficie d'une bonne lisibilité est invitée à se proposer pour obtenir une certification.

Comment mener une équipe ?

Chap. 5 How to lead a team

Dans les grosses structures, un directeur de l'ingénierie (engineering manager) est responsable des performances, de la productivité et du bien-être de chaque membre de son équipe, tout en veillant à ce que les objectifs de l'entreprise soient atteints.

Le responsable technique (tech lead) est responsable des aspects techniques du produit, y compris des décisions et des choix technologiques, de l'architecture, des priorités, de la vélocité et de la gestion générale du projet.

Le tech lead travaille généralement main dans la main avec le directeur de l'ingénierie pour s'assurer que l'équipe est dotée d'un effectif suffisant pour son produit et que les ingénieurs travaillent sur les tâches qui correspondent le mieux à leurs compétences et à leurs niveaux de qualification.

Dans les petites équipes, il y a souvent uniquement un tech lead : une seule personne qui peut s'occuper à la fois des personnes et des besoins techniques de son équipe.

Quand on écrit du code, on termine généralement sa journée avec quelque chose de tangible : "voici c'est ce que j'ai fait aujourd'hui". Quand on passe à un rôle de leader, à la fin de la journée on se retrouve généralement à penser "je n'ai rien fait du tout aujourd'hui". La santé sociale de l'équipe est tout aussi importante que la santé technique, mais aussi infiniment plus difficile à gérer.

Anti-patrons :

• Ignorer ceux qui livrent trop lentement "l'espoir n'est pas une stratégie"
• Ignorer les problèmes humains
• Être l'ami de tout le monde
• Transiger sur le niveau des embauches
• Traiter une équipe comme des enfants

Éléments positifs :

• Oublier son ego : s'excuser ne coûte pas cher
• Être un maître Zen
• Être un catalyseur
• Supprimer les obstacles
• Être un enseignant et un mentor
• Fixer des objectifs clairs
• Être honnête
• Mesurer le bien-être

Un moyen simple de mesurer le bien-être dans votre équipe est de demander à ses membres à la fin d'un one to one : "de quoi avez-vous besoin ?" ou "comment évaluez-vous votre bien-être sur une échelle de 1 à 5 ?".

Comment mener plusieurs équipes ?

Chap. 6 Leading at scale

La délégation va à l'encontre de tous nos instincts d'efficacité et de réussite.

Pensez aux dernières vacances que vous avez prises et qui ont duré au moins une semaine. Avez-vous continué de consulter vos e-mails professionnels ? Demandez-vous pourquoi. Les choses vont-elles s'effondrer si vous n'y prêtez pas attention ? Si c'est le cas, vous avez très probablement fait de vous un SPOF. Vous devez remédier à cela.

Avant d'accomplir une tâche, posez-vous cette question essentielle : suis-je vraiment le seul à pouvoir faire ce travail ? À moins que la tâche ne soit vraiment urgente, confiez le travail à quelqu'un d'autre.

La délégation est un appel au macromanagement.

Une erreur courante consiste à confier à une équipe la responsabilité d'un produit spécifique plutôt que d'un problème général. Le produit est une solution à un problème.

Protégez votre temps, votre attention et votre énergie. Divisez votre travail en trois groupes :

• Les 20% du bas ne sont probablement ni urgents ni importants, et très faciles à supprimer ou ignorer
• Les 60% du milieu peuvent contenir quelques éléments urgents et importants, mais c'est un mélange
• Les 20% du haut sont les choses impératives