Ne rien faire au travail

• La performance d’un ingénieur logiciel dépend moins d’un plus grand nombre d’heures ou de lignes de code que de travaux à fort impact au bon moment ; en temps normal, viser une utilisation à 80 %, avec environ 20 % de la journée loin de l’ordinateur, est efficace
• Dans les grandes organisations d’ingénierie, des opportunités dépendantes du temps comme le support d’un gros contrat, l’atténuation d’un incident ou le lancement d’une fonctionnalité majeure peuvent créer beaucoup de valeur ; si l’on est déjà trop occupé, on risque de les manquer
• En continuant à traiter des tickets de faible priorité, on finit par ne plus voir ce qui se passe dans les autres équipes, les mises à jour de l’équipe ou les incidents en cours, et il devient aussi plus difficile pour un manager d’identifier quelqu’un comme disponible
• Les moments où l’on ne fait rien permettent de récupérer du stress, de rester calme pendant la réponse aux incidents, de faire émerger de nouvelles idées et de garder de la concentration pour les tâches importantes
• Garder volontairement de la marge en temps normal, puis ne passer à 100 % d’intensité que lorsque l’enjeu est vraiment élevé, crée des conditions plus favorables pour devenir un ingénieur très performant

---

Opportunités à fort impact

• Beaucoup d’ingénieurs devraient moins travailler ; cela ne veut pas dire produire moins de code ou moins de changements, mais réduire le temps réellement consacré au travail dans la journée et ralentir aussi le rythme quand on travaille
• L’état par défaut devrait viser une utilisation à 80 % ; en l’absence de projet sous forte pression, cela implique de passer 20 % du temps de travail loin de l’ordinateur
• Dans les entreprises technologiques, les résultats dépendent fortement d’événements exceptionnels, et nombre des changements ayant eu le plus d’impact peuvent représenter un volume de travail étonnamment faible
• En développement logiciel, l’effort en lui-même n’est pas récompensé ; ce qui compte, c’est résoudre le bon problème au bon moment

• Trois cas possibles dans une grande organisation

  • Au moment de conclure un gros contrat enterprise, aider sur une fonctionnalité ou un correctif peut contribuer à faire aboutir le contrat
  • Il n’est pas toujours nécessaire que la fonctionnalité soit excellente ; il suffit parfois de montrer la volonté et la capacité à produire un changement concret
  • Prévenir ou atténuer un incident tôt peut réduire à la fois la perte de revenus immédiate pendant l’incident et la perte ultérieure liée au churn client ou au refus de signer un contrat
  • Savoir qu’il faut désactiver le bon feature flag peut à lui seul faire économiser des sommes importantes
  • Quand l’entreprise s’apprête à lancer une fonctionnalité importante, la réussite ou l’échec peut dépendre d’un changement minime, mais difficile à trouver
  • Cela peut être, par exemple, ajouter rapidement un nouveau champ dans les préférences utilisateur, ou corriger une ancienne fonctionnalité d’export de données enterprise laissée intacte depuis des années
  • La familiarité avec le système peut faire la différence entre un changement de quelques heures et un changement d’une semaine

• Dépendance au temps

  • Toutes ces opportunités sont dépendantes du temps ; on ne peut pas se connecter le matin et, au hasard, débloquer un gros contrat, atténuer un incident ou produire rapidement une fonctionnalité majeure
  • Être au bon endroit au bon moment ne suffit pas ; il faut aussi ne pas être déjà débordé

Garder de la marge

• Si l’on reste à 100 % d’utilisation en traitant sans arrêt des tâches de faible priorité, on rate les opportunités de travail à fort impact de deux façons
• Premièrement, quand on est trop occupé, on ne remarque même pas l’opportunité
  • On a moins de temps pour parler avec les personnes qui travaillent sur autre chose, lire les mises à jour de l’équipe ou examiner les incidents en cours
  • Le meilleur moyen de participer à un travail à fort impact est de proposer son expertise
• Deuxièmement, si l’on semble toujours occupé, il devient difficile pour un manager de nous faire participer
  • La deuxième meilleure voie d’accès est qu’un manager ou un product manager vous mette en relation en se disant : « cette personne a de la bande passante pour aider ici »
  • Les managers et les product managers assistent à des réunions auxquelles les ingénieurs ne participent pas, et ils savent donc souvent mieux quels travaux à fort impact sont en cours

Ne rien faire

• S’il faut libérer du temps pour les travaux à fort impact et ne pas se contenter d’enchaîner les tickets, alors, à l’échelle de quelques minutes, on peut littéralement ne rien faire
• Le software engineering peut être un métier stressant, mais ce n’est généralement pas un métier constamment stressant
  • Le stress survient dans des situations ponctuelles : incidents, travaux urgents sous forte pression, licenciements récents, etc.
• Si l’on aborde même les périodes de faible pression avec le même niveau d’urgence, on arrive déjà épuisé et irritable quand il faut gérer une situation vraiment tendue
• Même pendant une période de forte pression, l’attitude consistant à ne rien faire peut être utile
  • Un ingénieur peu habitué à l’astreinte a intérêt à ne pas se précipiter, et à prendre quelques respirations avant de rejoindre un appel ou de parler
  • En réponse à incident, il faut globalement « penser en mouvements lents »
• La plupart des incidents se résolvent d’eux-mêmes, et les changements appliqués dans l’urgence « au cas où ça aiderait » aggravent souvent la situation au lieu de l’améliorer
• En général, rien qu’en évitant de paniquer, on gère déjà mieux la réponse aux incidents que la plupart des ingénieurs
• Le temps où l’on ne fait rien crée de l’espace pour que les choses arrivent
  • Quand le cerveau a l’occasion de se reposer, de nouvelles idées ont plus de chances d’émerger
  • Lorsqu’on reçoit une tâche importante, on peut s’y consacrer pleinement au lieu de gérer en arrière-plan trois autres choses en parallèle
  • Quand on n’est pas occupé, on a simplement le temps de regarder autour de soi et d’absorber de nouvelles informations

Choisir délibérément de ne pas faire certaines choses

• Beaucoup d’ingénieurs sont mal à l’aise dans les situations où ils voient quelque chose à faire mais ne le font pas
• Cette tendance est un trait psychologique partagé par beaucoup d’ingénieurs logiciel, et c’est aussi en partie ce qui les rend adaptés à ce métier
• Pour créer du temps où l’on ne fait rien, il faut parfois se forcer délibérément à ne pas intervenir

• Éviter le travail de glue

  • En général, les ingénieurs devraient éviter le glue work
  • Le glue work désigne des tâches comme faire en sorte que les gens se parlent, mettre à jour la documentation d’un travail que l’on ne pilote pas, ou encore obtenir des ressources pour résorber la dette technique
  • La plupart des tâches de glue work reflètent le fait que l’organisation n’a pas explicitement donné la priorité à ce travail
  • Si l’organisation en faisait une priorité, il ne serait pas nécessaire qu’un individu se porte volontaire
  • Si le fait de ne pas en faire une priorité reste acceptable, alors prendre cette tâche est une perte de temps et peut agacer le manager
  • Et même si le fait de ne pas en faire une priorité est une grave erreur, la prendre en charge à titre individuel évite à l’entreprise d’assumer les conséquences de son erreur, au prix de votre carrière et de votre santé mentale
  • C’est une mauvaise affaire pour la personne concernée, un mauvais exemple pour les collègues juniors, et un mauvais précédent où quelqu’un d’autre finit par occuper le même rôle après un burnout
  • Si les conséquences sont vraiment graves, il faut laisser l’organisation en subir les effets pour qu’elle change sa politique

• Trop aider rend vulnérable

  • Vouloir trop aider vous rend vulnérable face aux personnes qui cherchent à obtenir du travail non rémunéré
  • Dans les entreprises technologiques, beaucoup de gens essaient d’extraire des ingénieurs logiciel du travail qui ne sera pas reconnu
  • C’est différent des tâches qui arrivent par les circuits normaux et sont récompensées via une promotion, un bonus ou le salaire habituel
  • Le travail problématique arrive par des voies informelles et provient de personnes qui n’ont ni la capacité ni la volonté de faire enregistrer officiellement ce travail à votre nom
  • Exemple : un product manager d’une autre organisation vous demande de sortir certaines statistiques parce qu’il sait que vous êtes bon sur les requêtes de données
  • Exemple : un ingénieur d’une autre équipe vous demande de faire du pair programming, mais vous fait en réalité écrire tout le code avant de soumettre le changement sous son propre nom
  • Faire ce type de choses de temps en temps est acceptable, et on peut aider les gens quand c’est possible
  • Mais il faut être capable d’exercer une contre-pression, en refusant ou en répondant avec plusieurs heures ou plusieurs jours de retard

• Ne pas surinvestir dans un travail susceptible de disparaître

  • Mieux vaut ne pas trop investir dans un travail qui a de fortes chances de disparaître
  • Si un product designer affine ce qu’il veut en temps réel, il ne faut pas réécrire entièrement la page toutes les heures
  • Exemple : il veut un en-tête de page d’une certaine façon à 9 h, le modifie à 10 h, puis le rechange à 11 h
  • Dans ce cas, il vaut mieux aller marcher ou ne rien faire pendant un moment, puis refaire une seule fois le travail l’après-midi à partir de la version la plus récente du design
  • Les grandes idées d’un manager sans réel poids politique sont aussi un cas fréquent
  • On peut souvent laisser passer le temps jusqu’à ce que le projet soit annulé
  • Mais si l’on évalue mal le niveau de soutien politique du projet, on peut passer pour quelqu’un de paresseux et se retrouver ensuite à devoir livrer dans l’urgence

Conclusion

• Les conseils et outils en software engineering sont souvent orientés vers la capacité à amplifier son effort technique : faire plus, prendre des projets plus vastes, écrire plus de code
• Pourtant, la réussite en software engineering ne se décide pas sur ces critères
• Elle dépend de la capacité à faire la bonne chose au bon moment, ce qui suppose de conserver délibérément une partie de son énergie pour autre chose que le travail quotidien
• Il est possible d’être un ingénieur très performant avec 80 % d’effort ; cela réduit même les erreurs stupides dues au stress et facilite l’engagement dans des travaux à fort impact qui génèrent de grands résultats
• Il y a aussi des périodes où il faut se mobiliser à 100 % ; deux ou trois fois par an, on peut travailler longtemps, avec une forte concentration, en pensant au problème toute la journée
• Mais il vaut mieux réserver cette façon de travailler aux moments où la récompense est vraiment élevée, et rester relativement détendu le reste du temps

[GN⁺]

Avis Hacker News

• Bon article, mais au final, le problème reste encore une fois celui des incitations
  C’est vrai que prévenir ou atténuer un incident tôt peut faire économiser beaucoup d’argent, mais ce que j’ai vu à répétition dans plusieurs entreprises, c’est que la prévention n’est pas reconnue, alors qu’empiler du combustible puis éteindre l’incendie inévitable permet d’être félicité deux fois. Même dans de “bonnes” organisations
  Je n’ai jamais réussi à me prendre au jeu de cette politique façon théorie des jeux, qui consiste à livrer délibérément du code pourri rapidement puis à en récolter le mérite. J’avais trop de fierté dans mon travail
  J’ai maintenu et développé pendant plus de cinq ans un framework destiné à éliminer toute une famille de problèmes qui empoisonnaient la version précédente du produit, mais l’équipe partenaire qui déployait du code pourri, provoquait des incidents puis les corrigeait recevait des éloges publics, tandis que notre équipe n’obtenait aucun mérite précisément parce que ces incidents n’existaient pas. C’est de la prévention impossible à mesurer

  • En théorie des jeux, une équipe qui crée des problèmes de manière répétée et fait fuir des clients devrait être sanctionnée en conséquence. Si ce n’est pas le cas, c’est peut-être que les problèmes causés par des livraisons rapides n’affectent pas autant qu’on le pense la rétention client
  • Il suffit de glisser quelques Thread.sleep(100000) un peu partout et d’attendre que ça casse. Ensuite, on devient la personne qui a héroïquement mené la longue lutte contre l’incendie jusqu’au vendredi minuit après la release
    Il ne faut pas se demander pourquoi c’est récompensé, et bien sûr, il arrive aussi que l’organisation change ses critères de récompense
  • À propos de l’idée que “on ne peut pas être récompensé pour l’absence d’incidents parce que ça ne se mesure pas”, philosophiquement, je pense qu’on peut aussi mesurer le poids du néant
  • C’est malheureusement tout à fait vrai, mais ce n’est pas la seule méthode
    Une approche honnête consiste à créer quelques outils complexes mais indispensables qui font que les autres ingénieurs viennent constamment me voir. On devient bon pour repérer les mauvais usages d’un outil donné, et si l’on pointe les bugs dans le code des autres en quelques secondes, on paraît bien plus intelligent qu’on ne l’est vraiment
    Dans l’idéal, l’outil doit être fiable, utile, mais complexe. Si d’autres développeurs tombent sur un bug en l’utilisant, ils continueront à venir me voir, et je pourrai leur montrer leur erreur. Pour que cette stratégie fonctionne, il faut que l’erreur soit presque toujours de leur côté et que mon code soit robuste
    Si un vrai bug est découvert dans mon code, de préférence un petit cas limite, il faut se montrer très humble et désolé, puis féliciter en réunion d’équipe le développeur qui a trouvé ce bug compliqué
    C’est mieux que d’obtenir du crédit en corrigeant son propre code bogué. Ça peut marcher avec des managers ou des juniors, mais les autres ingénieurs seniors finissent par détester ça
    Construire des outils complexes mais stables permet d’être reconnu de manière répétée, souvent bien plus que deux fois, et la reconnaissance des autres développeurs finit par remonter aux oreilles des managers. Les leaders intelligents savent que ce signal vaut mieux que des démos tape-à-l’œil
    Les leaders qui distribuent des éloges simplement parce qu’un développeur prototype vite finissent par apprendre à leurs dépens. Les jeunes fondateurs semblent souvent passer par cette phase où ils récompensent ce qui est superficiel
  • Je suis d’accord si on pose l’opposition de cette manière, mais il faut un peu de nuance
    Une partie du travail de création d’un produit ou d’un ensemble de fonctionnalités relève davantage de l’exploration que d’une excellente ingénierie. Parfois, il vaut mieux créer deux fonctionnalités assez bonnes pour découvrir ce qui a de la valeur pour les utilisateurs, plutôt qu’une seule fonctionnalité parfaitement solide
    J’ai toujours été du camp du “essayons d’abord, on verra ensuite”. Cela dit, je suis reconnaissant que quelqu’un avec une approche différente de la mienne ait créé git
    Il y a un équilibre à trouver, et cela dépend du degré d’exploration du problème qu’on traite. Ici, la “solidité” désigne, d’un point de vue purement ingénierie, la disponibilité, la maintenabilité, ou encore le risque de fuite des photos sensibles des utilisateurs

• Le passage sur “les gens qui essaient de soutirer du travail non récompensé” mériterait d’être encadré
  Surtout quand un product manager d’une autre organisation dit “vous êtes doué pour les requêtes de données, vous pourriez me sortir quelques stats sur X ?”, ou quand un ingénieur d’une autre équipe demande du “pairing” et qu’au final c’est moi qui écris tout le code pendant qu’il soumet discrètement le changement sous son nom

  • Là où je travaille, Principal Engineer est un titre rare, très convoité et bien rémunéré. Tous ceux avec qui j’ai travaillé à ce niveau étaient très compétents et humainement très bien, et j’ai un jour demandé à l’un d’eux comment il avait obtenu ce titre dans son entreprise précédente
    Sa stratégie consistait à aider les gens et à redistribuer activement le mérite. En 1:1 ou dans des réunions avec plusieurs niveaux de management, il soulignait régulièrement la valeur du travail de ses coéquipiers, ce qui lui a valu leur sympathie
    Quelques années plus tard, quand un projet avec beaucoup d’argent en jeu a pris du retard et que plusieurs ingénieurs clés ont quitté l’entreprise, il a fait des heures sup pour mener le projet au succès, et a obtenu le titre ainsi qu’une augmentation lors de l’évaluation suivante
    Ce projet a bien été l’effort final décisif, mais il n’était pas le seul ingénieur à faire des heures sup. Selon lui, sa promotion reposait sur la bonne volonté accumulée en attribuant le mérite aux autres tout au long de son ancienneté
  • Je pense que cela dépend du degré d’implication du manager. L’un des profils avec lesquels je n’ai pas envie de travailler, c’est la personne qui dit “ce n’est pas mon travail”
    J’ai envie de travailler avec des gens qui voient un problème et proposent une solution, que cela figure ou non dans leur fiche de poste
    Si mon travail n’est pas reconnu, c’est un problème de leadership. Refuser net en disant que ce n’est pas dans son périmètre ressemble à une voie vers une culture d’entreprise rigide et lente
  • La phrase à encadrer, c’est “ouvrez-moi un ticket”
  • C’est vrai, mais je ne le vois pas de manière aussi binaire. Au-delà du fait de protéger directement ma propre rémunération, j’ai aussi intérêt à aider l’entreprise elle-même à réussir, donc même si ça ne me vaut pas de parade, il peut être rationnel d’aider sur de petites demandes
    De même, il se peut qu’un jour j’aie moi-même besoin de quelque chose d’un collègue, et à ce moment-là je préférerais qu’il m’aide activement plutôt que de me renvoyer vers des “canaux officiels”. Les canaux officiels peuvent prendre bien plus de temps
  • Dans une bonne entreprise, il y a une culture, et les gens s’entraident
    Une conversation au déjeuner peut aider quelqu’un à comprendre quelque chose
    En revanche, faire plusieurs heures de travail pour quelqu’un, c’est peut-être une autre histoire

• Ce n’est pas pour être sarcastique, c’est davantage une observation, mais dans les organisations suffisamment grandes ou bureaucratiques, empêcher un problème à l’avance rapporte difficilement du mérite ou de la visibilité. Ce genre de résultat entre dans la catégorie du « travail qu’on est censé faire de toute façon ».
  Du coup, les gens doués en politique interne préfèrent parfois laisser l’incident se produire, puis se démener bruyamment sur les actions de suivi. L’astuce consiste à ne pas laisser l’incident devenir une catastrophe, et c’est un travail assez délicat.

  • Je l’ai appris tôt dans une organisation conservatrice. La prévention est risquée. Mieux vaut avoir une solution prête pour quand les choses tournent mal, car c’est seulement à ce moment-là qu’on peut obtenir l’approbation.
  • Tous les exemples de fort impact ressemblent à des choses difficiles à faire reconnaître.
    Si je sauve un contrat commercial, c’est l’équipe commerciale qui reçoit les applaudissements, et la commission aussi. Moi, je n’en touche pas une part.
  • Une catastrophe peut aussi être un bon signal vers le haut de la hiérarchie qu’il y a un problème dans l’organisation. Si vous éteignez héroïquement tous les incendies, votre supérieur le saura peut-être, mais le supérieur du supérieur du supérieur verra juste une organisation qui tourne très bien, avec tous les voyants au vert.
    Si vous laissez quelques éléments brûler, le supérieur du supérieur du supérieur verra cet incendie, et des améliorations pourront peut-être suivre. C’est peut-être même la façon la plus simple de communiquer avec eux.
  • La clé, c’est que les gens le remarquent. J’ai entendu dire que dans des administrations locales, on coupe parfois un programme populaire pour provoquer une réaction, puis on s’attribue le mérite de son rétablissement. Au passage, on peut aussi faire passer d’autres mesures nécessaires mais impopulaires.
  • On construit souvent une carrière et on distribue des bonus grâce au jeu du héros.

• J’avais à moitié écrit un texte sur ce sujet il y a longtemps, avec une métaphore de RPG fantasy. Quand on joue un personnage qui utilise du mana dans ce genre de jeu, on apprend vite qu’en vider la réserve à chaque petit combat, puis errer à sec, fait qu’il ne reste plus rien quand on en a vraiment besoin.
  L’énergie mentale qu’on dépense au travail n’est pas si différente. Si on en garde un peu en réserve, on peut l’utiliser stratégiquement quand un imprévu survient, sans mettre en danger sa santé, c’est-à-dire le burn-out.
  Et si vous avez déjà fait équipe dans ce type de jeu avec un joueur incapable de gérer son mana, vous savez aussi que ce n’est pas un très bon coéquipier.

  • J’ai constaté que si l’on n’est pas suffisamment mis au défi pendant un certain temps, il peut devenir extrêmement difficile de franchir le défi suivant.
    Dans tous les domaines, les moments où j’étais au sommet de mes capacités étaient ceux où j’avais assez de travail devant moi pour l’abattre régulièrement comme une machine, et où l’on me faisait suffisamment confiance pour travailler vers un objectif sans être interrompu sans cesse pour devoir tout expliquer. Les compétences augmentaient comme un feu de brousse et les tâches se terminaient plus vite que prévu.
    Malheureusement, les emplois qui savent tirer parti de cette structure sont très rares. Il y a trop de blocages et d’interruptions qui empêchent d’entrer dans un vrai travail en profondeur.
  • Dans mon cas, je finirais le RPG avec 29 éthers restés dans l’inventaire, alors que si je les avais utilisés plus tôt, il y aurait eu bien moins de grind.

• Si vous voulez faire s’effondrer un système, il suffit de le faire tourner à 100 % de sa capacité nominale. Il n’y a plus aucune marge ni aucune capacité pour absorber une nouvelle demande, donc la moindre perturbation fait basculer le système en mode échec permanent.

  • L’efficacité est l’ennemie de la résilience.
  • Cela dit, l’effondrement n’arrive pas. Quand les ingénieurs font un burn-out ou vieillissent, on recrute simplement de nouvelles personnes, et le cycle recommence.
    Le problème de textes comme celui-ci, ou de livres comme Peopleware / Slack, c’est qu’ils ne présentent pas de mesures concrètes suffisamment convaincantes pour pousser les comptables à essayer une autre approche.

• La métaphore qui a changé ma manière de voir les choses venait de “The Power of Full Engagement”. En gros : « Tu te comportes comme un athlète d’endurance de niveau mondial sans intersaison. Arrête. »

• Il y a beaucoup de sagesse là-dedans. Au-delà du fait de garder une partie de sa capacité pour les tâches qui ont une vraie forte valeur, je pense aussi que le software engineering n’est pas un métier qu’on peut bien faire en restant occupé en permanence.
  Quand on essaie d’écrire du code aussi vite que possible, on obtient rarement une bonne conception. Cet article n’aborde pas un autre aspect important : comment travailler à 80 % de capacité sans se faire réprimander par son manager.
  Cela demande un peu d’attention dans la communication et l’estimation du travail. Un bon conseil que j’ai reçu de développeurs seniors plus âgés dans mon premier vrai poste de programmation me reste encore aujourd’hui : estimez le temps que quelque chose prendra, puis doublez-le avant de l’annoncer à votre manager ou à l’utilisateur.
  Avec l’expérience, ce facteur peut descendre de x2 à quelque chose comme x1,5, mais le principe reste valable.

  • Kent Beck, dans Good News Factory ou peut-être dans une conférence, disait que son équipe ne s’engageait jamais sur plus de la moitié de ce qu’elle pensait pouvoir faire. C’est une bonne approche pour la durabilité.
    Ce qu’il faut optimiser et ériger en précédent, c’est la capacité à livrer de manière constante sur le long terme, à un rythme soutenable. C’est une course de fond, et les promesses excessives ne font qu’éroder la confiance. Or cette confiance est précisément le meilleur levier dont disposent les développeurs pour obtenir l’espace dont ils ont besoin.
    Il faut promettre peu, créer une réputation de fiabilité en tenant ce qu’on annonce, et obtenir ainsi la marge nécessaire pour ne pas finir en burn-out.
    Plus on devient senior, et surtout quand on devient lead, plus la définition de limites, la préservation de l’attention et la prévention du burn-out font partie du travail. Parce qu’il existe énormément de façons de se détruire soi-même.
  • Le conseil « doublez votre estimation avant de la donner au manager ou à l’utilisateur » est juste, mais je me demande s’il tient compte de la loi de Hofstadter.
    Même en tenant compte de la loi de Hofstadter, les choses prennent toujours plus de temps que prévu.
    https://en.wikipedia.org/wiki/Hofstadter%27s_law

• Pour avoir beaucoup travaillé dans des rôles en contact client, le pire piège que j’aie rencontré à plusieurs reprises était de devenir proche d’un client qui paie. Quand on est engagé comme expert pour aider, si le client est vraiment quelqu’un de bien, il devient incroyablement difficile de lui dire non.
  C’est encore pire quand cette personne n’est pas le décideur, mais quelqu’un à qui l’on impose de me forcer la main sur quelque chose. En tant qu’expert de confiance, il est facile de dire non quand le client lui-même a une mauvaise idée, mais si l’ordre vient de son supérieur, que je ne vois jamais directement, je me retrouve soit à passer pour un coût inutile, soit à devenir un béni-oui-oui qui laisse un monstre derrière lui.
  J’envie parfois les gens qui ont surtout fait du travail en interne. Eux pouvaient au moins essayer de convaincre quelqu’un quelque part dans la hiérarchie.

• Le passage sur le glue work est intéressant : quand je travaillais dans une grande entreprise, cela faisait explicitement partie de l’évaluation annuelle des performances. Google appelait cela la « citizenship », et je trouve que le terme saisit bien l’idée. En gros : « qu’avez-vous amélioré pour le reste des employés de l’entreprise ? »
  D’un côté, c’était un peu étrange. Ce n’était pas dans ma fiche de poste, donc techniquement c’était du travail non rémunéré, mais en même temps cela faisait partie des attentes officielles. D’un autre côté, c’était bien de travailler dans un endroit où chacun consacrait un peu de temps et d’efforts à améliorer l’environnement pour tout le monde
  En faire une exigence explicite pour tous permet aussi de contourner la culture toxique du « je suis un ingénieur rockstar, je suis trop occupé par des choses importantes, que quelqu’un d’autre fasse le glue work ». Et ce « quelqu’un d’autre », c’était généralement une femme, presque certainement moins bien payée que cet ingénieur rockstar
  Le texte original laisse entendre que l’entreprise devrait embaucher officiellement quelqu’un pour faire le glue work, mais en réalité c’est composé de trop de tâches disparates pour qu’on puisse facilement les confier à une seule personne. Par exemple, quel intitulé de poste couvrirait à la fois « rédaction de documentation, entretiens d’embauche pour des ingénieurs logiciel, organisation de séminaires d’équipe hors site » ?
  Mais toutes ces tâches étaient nécessaires, et l’exigence de citizenship permettait de répartir la charge plus équitablement
  Une meilleure formulation ne serait pas « ne faites pas de glue work », mais plutôt « ne soyez pas la seule bonne poire à faire du glue work non rémunéré ». Autrement dit, il faut promouvoir une culture où chacun en prend une part, et où cela est officiellement reconnu comme du travail

• Fonctionner à 80 % d’utilisation est une bonne habitude, et cela aide quand on n’a pas un manager de type contremaître qui exige 100 % toute la journée, tous les jours. Ces gens-là prennent le fait qu’un ingénieur logiciel réfléchisse calmement et tranquillement pour de la paresse ou de l’inaction
  C’est pourquoi le télétravail est le meilleur moyen de garder une partie de sa capacité en réserve et de préserver sa santé mentale
  Un peu de glue work peut rendre la vie professionnelle de tout le monde bien meilleure, et si personne d’autre ne sait comment s’y prendre, cela peut faire de moi une personne indispensable, voire un héros, dans l’équipe

  • Je trouve même que 80 %, c’est élevé. Et cela varie selon les développeurs
    Vu la manière dont j’ai du mal à apprendre, réfléchir et me lancer, mes 80 % ne ressemblent en rien aux 80 % d’un collègue techniquement plus solide
    Si l’on prend ne serait-ce qu’un peu en compte la neurodiversité, les 80 de l’un peuvent être les 120 d’un autre