À propos
Le merge, c'est le milieu du travail, pas la fin.
Je travaille sur toute la chaîne interfaces frontend, architecture backend, et l'infrastructure qui met les deux en production. La plupart de ce que je construis doit tourner pendant des années et être maintenu par quelqu'un d'autre que moi.
Ça change la façon de coder. Je préfère une architecture claire à une solution astucieuse, parce que le code astucieux est une dette que quelqu'un paie plus tard. J'écris les décisions avant qu'on en débatte. Et je préfère accompagner une fonctionnalité jusqu'au déploiement et rester dessus ensuite, plutôt que de la passer au moment de la revue.
La partie du métier qui m'intéresse le plus, c'est la deuxième livraison du même message les retries, les rejeux, les événements en double. Concevoir pour ce cas-là avant le chemin nominal, c'est ce qui sépare un système qui résiste aux vrais utilisateurs d'un système qu'il faut surveiller.
Méthode
Cinq règles qui tranchent les débats avant qu'ils commencent.
01
Résoudre le vrai problème avant d'ajouter de la complexité. La plupart des fonctionnalités sont le symptôme d'une question mal posée.
02
Une architecture claire et un code lisible survivent au code astucieux. Le prochain à ouvrir le fichier est le véritable utilisateur.
03
Le travail répétitif appartient à l'outillage, pas à la journée de quelqu'un. Si ça arrive deux fois, ça mérite un script.
04
Un système doit être observable, testable et ennuyeux en production. Une nuit mouvementée est un défaut de conception.
05
Un logiciel devient bon par le retour terrain, pas par la planification. Une hypothèse déployée vaut mieux qu'un document parfait.
Outils
Pas tout ce que j'ai touché ce vers quoi je vais réellement, dans l'ordre où j'y vais.
Contact
Les problèmes d'ingénierie qui méritent d'être résolus m'intéressent, tout comme les produits à construire correctement et les équipes où un ingénieur a le droit de porter une fonctionnalité de bout en bout.
Je réponds sous 24 heures.