Tools I'm thankful for

Software engineers sometimes have a reputation of being overly critical when it comes to tools and programming languages. The web is full of rants, heated debates and articles about what technology is "better" and which is "crap". It was thus refreshing to read an post titled Software I'm thankful for, that shone a light on some pieces of software in a positive light. In honor of this article, I've decided to go through the same exercise.


Python was my gateway to becoming a software engineer. It was the first programming language I loved, and I still do to this day. I wrote Python code professionally for a an AI startup, an e-ticketing startup, the Scottish government, a global hosting provider, a huge observability SaaS. I've written large Python webapps and quick Python scripts. I've written large asynchronous task workflows processing payments, trained machine learning models, written self-documented REST APIs, found my house listing by scraping the web, monitor the level of the river close by, all of that in Python.

I also write Python code to maintain my own infrastructure, that I deploy via ansible, itself written in Python. This blog is generated via Pelican, which is written in Python. I've started to play with a Raspberry Pi Pico, that I program in ... CircuitPython. It's ubiquitous, and I've heard it be called "The second best tool for every job", meaning that it probably won't be the most performant tool for what you're working on, but you'll make progress really fast.

Learning and programming Python has taught me many programming concepts, such as object-oriented programming, functional programming, unit testing, dataclasses, metaprogramming, REST APIs, HTTP, JSON, etc.

I however now realize that it also allowed me to get introduced to lower-level concepts, such as ioctl, sockets, system calls, file descriptors, etc, through the reassuring lens of the Python standard library, instead of having to interact with these concepts in C, which was much more intimidating (and still is today).


The first time I was introduced to Docker was at a Python meetup in Lyon, circa 2013. After the 30 minute long presentation, I still had no clue as to what any of it meant and why I'd ever need it and pretty much shrugged it off. As the Docker ecosystem flourished and the dust settled, I started to understand the appeal.

Do you need to run redis to prototype against? Just run docker run redis and voila. Do you want to run calibre-web on your local VPS without having to install its dependencies in your system libraries? Sure.

Docker allowed me to self-host a collection of tools that I use every day, package and run applications in extremely large production environments, spin up development environments without having to pollute my system libraries. It boosted my productivity and became part of my day-to-day workflow. None of these are the real reason why I'm thankful for Docker.

I've seen many companies break down their monolith into dockerized microservices. The commonly invoked reasons are allowing teams to chose their own language for each project, and helping the horizontal scaling of some load-critical apps. As useful Docker was to start a single container, it didn't solve the issue of starting several containers that could communicate with each other on a single host. Enter docker-compose, which in turn didn't solve the issue of orchestrating containers on a fleet of nodes. Enter Mesos/Marathon, Docker Swarm, Kubernetes, Amazon ECS, etc.

The beef I have with Docker is that the hype around its ecosystem caused small companies to onboard immense amount of complexity from the absolute get-go, to help with recruiting. Because engineers want to build experience with Kubernetes, these companies find themselves dividing their attention between grappling with its inherent complexity, distributed tracing, image recycling policies, RBAC, etc, and building their actual core value.

This is why I'm thankful for Docker and its ecosystem. I believe I've seen situations in which it truly was critically useful, and I'll now be able to differentiate between situations in which we need it, and situations in which we only wished we did.

Raspberry Pi

Before I joined OVH, the only sysadmin experience I had was tinkering with my Raspberry Pi. Thanks to that 35$ matchbox-sized computer, I got to learn iptables and systemd, port forwarding, ssh hardening, file system checks and repairs. But really, the crucial point is that I was able to learn all that by making mistakes. I'd rather learn about why you need to be careful with iptables -j DROP in the comfort of my own home than in a production, high pressure, environment. I can't stress the impact that learning without the fear of public failure had on me.

I'm now getting into electronics through the Raspberry Pi Pico, which opens a whole new exploration and tinkering domain for me!

The terminal

The terminal is a truly important part of my day as a software engineer. It's really what allows me to feel in control. Like Python, it became a familiar tool in which I could discover entirely new domains, interact with new systems and concepts. I learned so much from it that I decided to help people out getting familiarized with the terminal and the shell.