Un jour, j’en avais assez d’attendre que mes dépendances OCaml se téléchargent à chaque build. J’ai écrit un petit truc pour les mettre en cache. Ça m’a fait gagner quelques minutes par jour, j’étais content.
Et puis je me suis rendu compte que le même petit truc, posé non pas sur ma machine mais sur le réseau de la CI, faisait gagner ces minutes à chaque build de chaque personne de l’équipe. Le même code. Exactement le même. Mais d’un côté il m’aidait moi, et de l’autre il aidait tout le monde, tout le temps.
C’est resté dans un coin de ma tête depuis. Ce qui décide de l’impact d’un travail, ce n’est presque jamais sa difficulté technique. C’est l’endroit où on le met.
Le levier, c’est la position
Un outil que vous faites pour vous divise votre temps par deux sur une tâche. Le même outil, pensé pour toute la CI, divise le temps de tout le monde, tous les jours. Le multiplicateur n’est pas dans les lignes de code, il est dans le fait qu’elles sont sur le chemin de dix personnes au lieu d’une.
Ça paraît évident dit comme ça. Ça l’est beaucoup moins dans le quotidien, parce que la plupart des frottements qui coûtent cher sont devenus invisibles. Tout le monde re-télécharge les mêmes paquets, tout le monde recopie le même bout de Terraform d’un projet à l’autre, tout le monde perd le même quart d’heure à comprendre pourquoi le déploiement ne part pas. Personne ne le compte, parce que c’est normal. C’est devenu le décor.
Le travail qui compte pour dix commence là : voir le frottement que tout le monde a arrêté de voir, et décider de l’enlever pour les autres.
Un exemple bête, et pourtant
Sur une plateforme où je suis passé, chaque nouvelle application arrivait avec les mêmes trois besoins : un déploiement, un service, un espace de noms. À chaque fois, quelqu’un repartait d’un fichier vide, recopiait ce qu’il avait sous la main, se trompait sur un détail, et le débuggait un après-midi.
On a fait un seul module Terraform qui décrit ces trois choses, appelé une fois par application. Rien de malin. Une nouvelle appli, ce n’est plus une page blanche, c’est une route déjà tracée. Le gain sur une appli est petit. Sur trente applis et trois équipes, il change la vie, et il change autre chose aussi : tout le monde déploie de la même façon, donc tout le monde peut aider tout le monde.
C’est ça le vrai bénéfice, en fait. Pas les minutes gagnées. L’uniformité. Quand la bonne façon de faire est aussi la façon la plus facile, les gens la prennent sans qu’on ait à les convaincre.
Ce n’est pas un travail qui se voit
Il y a un problème avec ce genre de travail. Il ne rentre pas bien dans un sprint. Personne ne vous a demandé de faire le cache, ou le module partagé. Ce n’est le ticket de personne. Ça a l’air de rien, et quand c’est bien fait, ça devient tellement naturel que plus personne ne se souvient de la douleur d’avant.
Vous ne serez pas félicité pour avoir supprimé un problème que les gens avaient arrêté de remarquer. C’est la rançon du truc. Le meilleur outil est celui qu’on oublie, parce qu’il marche.
Il faut donc le faire pour une autre raison que la reconnaissance immédiate. Je le fais parce que c’est, très concrètement, la façon d’avoir un impact plus grand que ses dix doigts. Je ne taperai jamais assez vite pour compenser dix personnes qui perdent chacune un quart d’heure par jour. Mais je peux enlever ce quart d’heure une fois, pour tout le monde.
Où se placer
Alors quand je regarde une plateforme, je ne me demande plus seulement « qu’est-ce qui ne marche pas ». Je me demande « qu’est-ce que tout le monde refait dans son coin ». C’est rarement la chose la plus difficile techniquement. C’est presque toujours celle qui a le plus d’effet.
Le meilleur travail que j’ai livré ces dernières années n’avait rien d’impressionnant. C’était souvent ennuyeux à écrire. Mais c’était posé au bon endroit, et ça tournait pour tout le monde. À choisir, je préfère ça à du code brillant que je suis le seul à faire tourner.