Pourquoi j'écris des livres en tant qu'ingénieur
On me demande à peu près deux fois par mois pourquoi j'écris des livres en travaillant à temps plein comme ingénieur. L'implication est généralement que c'est un usage inefficace du temps. La réponse honnête, c'est que l'écriture est devenue la chose la plus utile que je fais pour ma carrière d'ingénieur, et que les livres sont l'artefact d'une habitude, pas son objectif.
Trois raisons de continuer.
L'écriture est le meilleur outil de débogage de ma propre compréhension
Je l'ai appris en commençant le premier livre, Building AI Agents for Software Engineers. Je construisais des agents pour des clients depuis plus d'un an. Je pensais comprendre les agents. À la minute où je me suis assis pour expliquer ce que fait vraiment une boucle de tool-use, dans l'ordre, sans esquive, j'ai découvert que la moitié de ce que je « comprenais » était de l'intuition.
J'avais le sens de ce qui marche. Je n'avais pas de modèle propre du pourquoi. L'écriture force le modèle propre. Chaque fois que j'attaquais un chapitre en pensant maîtriser la matière, je tombais sur une section où mon modèle mental avait un trou que je contournais sans m'en rendre compte. Le livre est le résidu du rebouchage de ces trous.
Ça arrive aussi avec le code, mais plus lentement. Le code laisse livrer quelque chose qui marche sans jamais savoir précisément pourquoi. Un livre, non.
Les livres me forcent à confronter mon expérience à la rigueur
Quand j'avance une idée dans un fil Slack, elle vit une heure et disparaît. Quand je l'avance dans un livre que 4 000 personnes pourraient lire, je la vérifie trois fois. Je lance le code. Je relis la doc. Je vérifie si ce dont je me souviens en 2022 tient toujours. La friction est bonne.
Le deuxième livre, AWS Cost Optimization, est celui où ça a frappé le plus fort. J'avais des opinions sur le FinOps issues de missions client que j'aurais avancées sans broncher en conversation. La moitié a survécu au contact des vrais chiffres. L'autre moitié était « vrai en 2022, partiellement vrai aujourd'hui, faux dans deux régions AWS, compliqué ailleurs ». L'écriture a forcé la précision.
Le troisième livre, AI Security, est celui où j'ai le plus appris parce que le champ avance le plus vite. Les menaces d'il y a six mois ne sont plus forcément les menaces d'aujourd'hui. Écrire dessus m'a tenu à jour d'une façon qu'un projet client unique n'aurait pas permis.
La portée dépasse l'argent
Les royalties sont correctes. Ce n'est pas le sujet. Le vrai gain, ce sont les gens qui m'écrivent six mois après la sortie pour me dire qu'ils ont rencontré exactement le bug du livre, que le contournement a marché, et qu'ils voulaient me remercier. C'est arrivé assez souvent pour que je tienne un dossier.
J'ai reçu des mails d'ingénieurs dans des boîtes que je connais de nom. J'ai reçu des mails d'étudiants qui préparaient des certifications AWS. J'ai reçu un mail d'une personne qui me disait qu'elle s'apprêtait à déployer quelque chose contre lequel le livre prévenait précisément, qu'elle s'est rattrapée au dernier moment, et qu'elle a évité 48 heures d'incident à son équipe. Je ne sais pas si elle exagère, mais je prends.
Ce genre de portée est difficile à obtenir autrement. Je peux livrer une fonctionnalité ce trimestre qui aide cent utilisateurs internes. Le livre aide des inconnus pendant des années.
Si vous pensez en écrire un
Faites-le. Même si 12 personnes le lisent, vous serez l'une d'elles, et vous serez meilleur ingénieur. Le premier livre est le plus dur, dans des proportions déraisonnables, surtout parce qu'on ne croit pas encore que sa propre expérience vaut d'être écrite. Elle vaut. Quoi que vous ayez fait ces trois dernières années, écrivez ce que vous en avez appris, et publiez-le. L'audience pour « l'ingénieur qui a vraiment livré ce truc » est plus grande que l'audience pour « l'expert ».
Commencez petit. 80 à 120 pages suffisent largement. N'écrivez pas l'œuvre magistrale. Écrivez le livre que vous auriez aimé qu'on vous tende il y a 18 mois.