I’m a 52 years old French guy, father of 2 boys and a princess.
I’m an entrepreneur paid to solve complex problems involving computers, usually by building tools (software) or manipulating huge quantity of data, or sometimes coaching or managing people.
On my free time I like to do the exact same things as it’s my passion. (More references on my Linkedin profile)
I’m an unorthodox person, so instead of trying to paint an inaccurate portrait of myself, here are some facts:
I’ve been coding since I was 13 (it was in BASIC at the time).
I first installed Linux in 1993 (it was a Slackware)
I loved Perl enough to create a user group and (co-)organize national event.
Every developer has lived through this scene: the adrenaline spike when a production incident is announced. That mix of dread about what you are going to find and frenzy to collect any piece of information that will let you understand and then fix the problem. It happened to me again a few days ago. I can still picture myself rushing to the logs, and I still remember the frustration of finding nothing but basic information and an unhelpful error message: “Unable to load cache”.
But before you picture me as a theoretical physics genius or a crackpot in need of a straitjacket, let me explain.
I am currently working on Metarc, a metacompression tool (understand: applying smart transformations to certain structures before handing off to a classical compressor like zstd). If you have never heard the term, you will understand in 5 minutes. If you are a compression expert, hang on, you might find food for debate.
My psychological profile is INTJ1, also known as the Architect, and I spent a good part of my life proving that this label fit… in the worst possible way.
Years of having a multitude of ideas
on analysis systems (Blockchain, Productivity)
on personal development methods (Memory, Discipline, Learning)
on algorithms (routing, metacompression, encryption)
on tools (format conversion, project management, system administration)
Years of producing hundreds of ideas in a row, for nothing, or worse, only to see some of them realized by others years later.
I have always been fascinated by compression algorithms — I was 15 when I “invented” Run Length Encoding (before learning it had been discovered more than 20 years before I was born). I marveled at the visual simplicity of Huffman coding, and at the cleverness of Lempel-Ziv which dynamically builds its dictionary.
These algorithms are powerful, and it is no coincidence that they are continuously improved and combined to produce increasingly more powerful algorithms: Brotli, zstd.
In computing, the aphorism “Less is More” comes up often.
With Jujutsu (jj), it takes a very concrete form: a simpler mental model can reduce the daily friction of version control.
In this article1, I will not try to “prove” that jj is superior to git. I will show, on a concrete case, why some common operations: interrupting work in progress, reorganizing changes, fixing a non-atomic commit or resolving a conflict, become more natural with jj.
Sometimes an investigation tells a different story than the one you expected.
That’s what happened to me recently while investigating why a pod was ending up OOMKilled two to three times a day.
A quick look at the memory of the incriminated pod doesn’t show the typical rising curve of a memory leak. I’m missing data just before the OOM (because it’s always when your metrics system is migrating that this kind of incident happens), but with the day’s data, the cause seems to lie elsewhere.
Faced with an AI capable of compiling our intentions into working programs, I ask myself: does our craft reduce to assembling syntax, or does it hide a dimension that is by nature beyond computation?
I was 17 when I finally got my hands on “The Art of Computer Programming” by Donald Knuth.
At the time, in 1989, reference books on programming were rare and the 4 volumes of TAOCP had the status of a “bible”; it remains for me a reference work that every computer scientist should read.
What is the definition of the different types of tests?
What is the ideal code coverage percentage?
How do you handle flaky tests? Slow tests?
And if I address these questions quickly today, it is more for completeness than out of real interest.
These questions are not specific to TDD; they are common to software testing as a whole.
“Nobody use it. It’s a dead language. It’s a technology of the past…”
Are the kind of statement you’ll be likely to hear about Perl nowadays.
Nonetheless, I’ve landed one of the most exciting mission I’ve ever had because of Perl.
I’ve met great people, because of Perl.
I’ve solved issues in no time, because of Perl.
So, there’s no chance I’ll drop Perl any time soon.
