Je suis un Français de 54 ans, père de 2 garçons et d’une princesse.
Je suis un entrepreneur payé pour résoudre des problèmes complexes impliquant des ordinateurs, généralement en concevant des outils (logiciels) ou en manipulant d’énormes quantités de données, ou parfois en coachant ou gérant d’autres personnes.
Sur mon temps libre, j’aime faire exactement la même chose, comme c’est ma passion.
Je suis une personne non conventionnelle, alors au lieu de vous peindre un portrait imprécis de qui je suis, voici quelques faits :
Je programme depuis que j’ai 13 ans (c’était en BASIC à l’époque)
Ma première installation de Linux remonte à 1993 (C’était une Slackware)
J’ai aimé le langage Perl assez pour créer un groupe d’utilisateur et de (co-)organiser une conférence nationale sur le langage.
Mon profil psychologique est INTJ1 aussi appelé Architecte, et j’ai passé une bonne partie de ma vie à prouver que cette étiquette était adaptée…de la pire des manières.
Des années à avoir une multitude d’idées
sur des systèmes d’analyse (Blockchain, Productivité)
sur des méthodes de développement personnel (Mémoire, Discipline, Apprentissage)
des algorithmes (routage, metacompression, chiffrement)
des outils (conversion de formats, gestion de projet, administration système)
Des années à produire des centaines d’idées à la chaîne pour rien ou pire pour en voir certaines réalisées par d’autres des années plus tard.
Et si le vrai gain n’était pas au niveau des octets ?
J’ai toujours été fasciné par les algorithmes de compression, j’avais 15 ans quand j’ai “inventé” le Run Length Encoding (avant d’apprendre qu’il avait été découvert plus de 20 ans avant ma naissance). Je me suis extasié sur la simplicité “visuelle” du codage de Huffman, de l’astuce de Lempel-Ziv qui construit dynamiquement son dictionnaire.
Ces algorithmes sont puissants, et ce n’est pas un hasard s’ils sont sans cesse améliorés et encore combinés pour produire de nouveaux algorithmes encore plus puissants : Brotli, zstd.
En informatique, l’aphorisme “Less is More” revient souvent.
Avec Jujutsu (jj), il prend une forme très concrète : un modèle mental plus simple peut réduire la friction quotidienne dans la gestion de versions.
Dans cet article1, je ne vais pas chercher à “prouver” que jj est supérieur à git. Je vais montrer, sur un cas concret, pourquoi certaines opérations courantes : interrompre un travail, réorganiser ses modifications, corriger un commit non atomique ou résoudre un conflit, deviennent plus naturelles avec jj.
Parfois, une investigation raconte une autre histoire que celle que vous attendez.
C’est ce qui m’est arrivé récemment en cherchant pourquoi un pod finissait en OOMKilled deux à trois fois par jour.
Une rapide observation de la mémoire du pod incriminé ne montre pas la courbe croissante typique d’un memory leak. Je manque de données juste avant le OOM (parce que c’est toujours quand votre système de métriques est en train de migrer que ce type d’incident se produit) mais avec les données de la journée, la cause semble se trouver ailleurs.
Alors que les méthodes se font toujours plus nombreuses, les livres toujours plus prescriptifs, les outils toujours plus performants, la démarche toujours plus industrielle, l’industrie du logiciel continue à produire autant de dette, de retard et de bugs qu’auparavant. C’est un secret de polichinelle et pourtant rien ne change. Pourquoi ? Peut-être est-il temps de chercher la cause là où trop peu regardent.
Laissez-moi vous raconter une histoire.
Imaginez, vous êtes embauché en tant que chef de projet informatique, dans une startup où le développement est complètement stoppé :
Face à une IA capable de compiler nos intentions en programmes fonctionnels, je m’interroge : notre métier se réduit-il à l’assemblage de syntaxe, ou cache-t-il une dimension qui échappe par nature au calcul ?
J’avais 17 ans quand j’ai enfin mis la main sur “The Art of Computer Programming” de Donald Knuth. À l’époque, en 1989, les livres de référence sur la programmation étaient rares et les 4 volumes de TAOCP faisaient figure de “bible”; il reste encore pour moi un ouvrage de référence que chaque informaticien devrait lire.
Ça fait 4 ans maintenant que je n’ai rien écrit sur ce blog. Une Pandémie, un déménagement en Thailande, une modification de mon infrastructure d’hébergement sont passés par là entre temps, et sans m’en rendre compte, j’ai perdu l’habitude de partager ici.
Mais le temps passant, l’envie s’est faite de plus en plus forte, le temps de réactiver ma chaine de CI/CD, je suis à nouveau prêt a commiter mes articles et mes idées vers ce blog.
Mieux vaut tard que jamais…
Si vous suivez mes blogs/podcasts vous savez déjà que je suis un fan du langage Go, aprés avoir été pendant plusieurs années un utilisateur passionné de Perl.
Ce que vous ignorez peut-être c’est que j’ai utilisé ou continue à utiliser de nombreux autres langages, et que je continue régulièrement à apprendre de nouveaux langages.
Ces 10 dernières années j’ai un peu changé ma façon de faire : pour m’immerger complètement dans le langage que j’apprend, j’essaie pendant un an de réaliser tous mes nouveaux projets dans ce langage. Ce n’est pas forcément le meilleur choix d’un point de vue pratique (un outil ligne de commande en Javascript peut être un peu lourd à déployer par exemple) mais ça me permet de m’impliquer à fond dans l’apprentissage d’un langage.
