2025-06-06 08:00:00
I watched the Champions League final the other day when it struck me: I’m basically watching millionaires all the time.
The players are millionaires, the coaches are millionaires, the club owners are millionaires. It’s surreal.
This week I watched John Wick Ballerina and, again, there’s Keanu Reeves, who is a millionaire, and Ana de Armas, who is as well.
Yesterday I heard about Trump and Musk fighting. They are not millionaires, they are billionaires!
As I’m writing this, I’m watching the Rock am Ring live stream, a music festival in Germany. Weezer is playing. These guys are all millionaires.
I don’t know what to make of it. It’s a strange realization, but one that feels worth sharing.
I could go down the road of how this fixation on elites distracts us from the people nearby, but that’s not quite it. What interests me more is how normalized this has become.
Maybe it’s just the power law in action: a few rise to the top, and we amplify them by watching. But most people in every field aren’t millionaires. We just don’t see them.
You’re on a tiny blog by a tiny man and if you made it this far, I appreciate you. It looks as if you care about the little stories as well.
If you’re anything like me, you’re not only enjoying the little stories, you’re actively seeking them out – but there’s so few of it nowadays. Yes, there are still places where people share their stories, but you need to know where to look.
If anything, we all should share more. Write about the little things, the everyday moments, the people you meet, the things you care about. Don’t live anybody else’s life!
Rivers Cuomo, Weezer’s lead singer, once wrote:
My motivation is much different now than it was then: then I was terribly discontent and dreaming of being a classical composer, a writer, or basically anything that I wasn’t; now I just want to enjoy my life and do the responsible thing—graduate.
That’s from his Letter For Readmission To Harvard (2005).
Nobody forced him to go back to Harvard after so many years. He was a freaking millionaire rock star by then.
And yet, he did.
He stopped pretending and started living.
We don’t have to keep watching other people’s lives.
Live your own.
2025-06-02 08:00:00
Paolo was a plumber.
People knew him as a reliable and thorough craftsman. He fixed the pipes in his small town and made a good living doing so.
One day, his friend Mario told him that he’d bought a plumbing machine. Paolo was intrigued and asked how it worked.
“It’s magical!” said Mario. “I show it what’s broken, and it fixes the problem in no time!” Paolo asked if he could watch the machine work.
The next day, Paolo and Mario took the machine to a house with a broken pipe. Paolo watched as Mario positioned the machine by the pipe. “Beep boop,” and the machine started working, and quickly. Paolo noticed the machine turned the wrench back and forth instead of steady pressure - something he could adapt for his own work. Within minutes, the pipe was fixed.
“Soon no one will need plumbers anymore,” said Mario. “I can already do the work of ten plumbers with this machine!”
That night, Paolo couldn’t sleep. He thought about his job and how it might change. He loved being a plumber and helping people. But what if machines really took over?
Within a few weeks, Paolo’s phone stopped ringing. People were calling Mario instead because he did quicker, cheaper work. Some of Paolo’s old customers told him he was “old-fashioned” and “out of touch.”
In the past, none of his customers had ever complained about his work. He always took time to do things right. He would check every joint, seal every pipe, and make sure everything was perfect before leaving. Sometimes he noticed other problems that needed fixing and he would offer to fix those too.
Then one day, he got a call from an old customer. It was an emergency. The pipes in the restaurant were leaking and they needed help fast. Paolo rushed over and found a mess. He got to work and fixed the problem.
“We just got it fixed the other day!” When Paolo asked who did the work, the owner said it was Mario.
From that day on, more people called Paolo. They all had problems after working with Mario and the machine. Paolo kept finding the same mistakes: pipes not properly sealed, joints not aligned correctly, leaks temporarily fixed with instant glue. Sometimes the machine would add extra parts: pipes that ended nowhere, valves that didn’t connect to anything. Paolo recognized these as signs of the machine at work.
Paolo called Mario and told him what he’d found. Mario knew about the issues: “I told it to fix it, but it didn’t work right. Even when I asked multiple times and was very polite.” And worse: “One time I looked away for a moment and the machine started remodeling the bathroom! It added a new sink that wasn’t there before.”
Paolo asked why he didn’t just fix it himself. “I can’t,” Mario said. “I don’t know how to do it without the machine.”
Mario had been a reputable plumber before he got the machine. Now he was relying on a machine that didn’t always work. Worse, Mario didn’t own the machine but rented it from a company far away. The rent was cheap in the beginning, but now it was getting more expensive.
Paolo realized that Mario wasn’t the only one. Many plumbers were using machines now, and new plumbers were learning machines instead of tools. It wasn’t just plumbers—electricians, carpenters, other tradespeople were all relying on machines. The machines caused problems, but the company promised they would fix everything and get better with time. They kept updating the machines and gave them fancy names, but the problems remained.
Paolo just kept working. He fixed what the machines broke. His customers called him back for more work. Soon his phone was ringing like before.
A while later, a salesperson came to town with a new machine. Paolo heard Mario talking to him at the coffee shop.
2025-05-24 08:00:00
One of the most harmful pieces of advice is to not reinvent the wheel.
It usually comes from a good place, but is typically given by two groups of people:
Either way, both positions lead to a climate where curiosity and exploration gets discouraged. I’m glad that some people didn’t follow that advice; we owe them many of the conveniences of modern life.
Even on a surface level, the advice is bad: We have much better wheels today than 4500–3300 BCE when the first wheel was invented. It was also crucially important that wheels got reinvented throughout civilizations and cultures.
Note: When I say “wheel” throughout this post, please replace it with whatever tool, protocol, service, technology, or other invention you’re personally interested in.
“What I cannot create, I do not understand”
– Richard Feynman, Physicist and Nobel Prize Winner
To really understand something on a fundamental level, you have to be able to implement a toy version first. It doesn’t matter if it’s any good; you can throw it away later.
In Computer Science, for example, there are many concepts that are commonly assumed to be beyond the abilities of mere mortals: protocols, cryptography, and web servers come to mind.
More people should know how these things work. And therefore I think people should not be afraid to recreate them.
Too often, fundamental things are taken for granted. For example strings or paths are super complicated concepts in programming. It’s a great exercise to implement a string or a path library yourself if you’re interested in how they work.
Even if nobody ends up using your work, I bet you’ll learn a lot. For example:
On the last point, everything is a tradeoff and there are dozens, sometimes hundreds of footguns with every toy problem.
Along the way, you will have to make decisions about correctness, simplicity, functionality, scalability, performance, resource usage, portability, and so on.
Your solution can be great in some of these things, but not all of them and not for all users. That also implies that existing solutions have flaws and might not be designed to solve your particular problem; no matter how well-established the solution is.
Going down rabbit holes is fun in its own way, but there is one other benefit: It is one of the few ways to level up as an engineer… but only if you don’t give up before you end up with a working version of what you tried to explore. If you jump between projects too often, you will learn nothing.
There are great reasons to reinvent the wheel:
Who knows? The wheel you come up with might not be the best use for a car, but maybe for a… skateboard or a bike? Or you fail building a nicer wheel, but you come up with a better way to test wheels along the way. Heck, your wheel might not even be meant for transportation at all! It might be a potter’s wheel, “a machine used in the shaping (known as throwing) of clay into round ceramic ware” according to Wikipedia. You might end up building a totally different kind of wheel like a steering wheel or a flywheel. We need more people who think outside the box.
Of course, don’t disregard the works of others – study their work and reuse where you see fit. Don’t reinvent the wheel out of distrust or ignorance of the work of others. On the other side, if you never tried to put your knowledge to the test, how would you ever learn enough about your field to advance it?
I observed you can move very quickly by running little experiments. Especially in software engineering, building small prototypes is cheap and quick. Solve your own problem, start small, keep it simple, iterate.
So, with all of the above, here’s my advice:
Reinvent for insight. Reuse for impact.
2025-04-13 08:00:00
As kids, our parents established a few simple rules that we would all follow, no matter the circumstances. One of them was that we’d always have dinner together in the evening, typically around 6pm.
In almost two decades, they never broke that rule. We had dinner on 9/11 and when mom was at the hospital. It’s not always easy.
There’s a nice thing that happens when you have such a golden rule: it has ripple effects. Since we had dinner together every evening, we would always have time to talk about the day. Problems would be uncovered earlier. We would know about each other’s appointments for the next day. It provided structure throughout the rest of the day. It put things into perspective. It grounded us.
As a kid, it sounded like one of those “stupid” rules only grown-ups would come up with. And in fact, my parents knew that it was stupid. They did it anyway. As a kid, that made their life look extremely dull and boring. I remember pitying my dad once for being such a slave to society. Yet, they persisted because without it, things would fall apart. Skipping dinner is about way more than skipping dinner.
It’s a simple rule with little room for interpretation. However, it’s not easy: there are times when you have to drop something else to make dinner at 6 work. That’s when the rule counts the most! That’s what makes or breaks it.
Following the rule 90% of the time is much easier than following it 100% of the time. You have to make sacrifices. You have to say no sometimes. That’s the price it takes to stick to the rule.
Yes, such rules “sound” stupid, but there’s a deeper, almost stoic realization to it: Life is complicated and will throw obstacles in your way. But if you really want to make progress, you have to find a way. If nothing else helps, make up a stupid rule; and the harder you struggle, the more specific the rule should be.
Dinner. Every day. At 6 o’clock.
Only now am I discovering this for myself. In 2019, I mentioned to my friend Abu that I felt bad for not doing any sports. It’s not that I didn’t try, it’s just that nothing lasted for long. He suggested going for a run together on Tuesdays – no matter what. I thought that was ridiculous. I told him that it couldn’t possibly work. Why Tuesdays of all days!? It felt so random. In my mind, I started negotiating. But there’s no point in negotiating with irrationality. Fast forward 5 years, and I still run every Tuesday.
I actually suck at running. My pace isn’t fast. The distance isn’t far, but it’s a solid effort. Time was made. It worked out. Again, it had positive rippling effects: I ran on Crete in Greece and Sardinia in Italy. Different people joined me on my runs. If Tuesday finds me elsewhere, my running shoes come along. Now, did I always manage to run on a Tuesday? No. It’s not easy! But I always gave it a solid attempt and I can remember each time I didn’t run. Since Abu and I run together a lot, we would talk about our week. If we didn’t make up that rule, we would never have started to know each other on such a deep level.
Some people won’t understand when you tell them that you have to do a thing “no matter what.” Instead of telling them I have to go for a run, I say I’m busy that evening. Nobody ever asks any questions.
With “no matter what” there can be serious consequences. If you have to take care of a loved one, you can’t skip a day. Or if you’re an Air Traffic Controller, failure is not an option.
My stakes are not as high, but I take them very seriously.
“No matter what” rules aren’t habits, at least not in the beginning. They can, however, turn into super strong habits with time.
I found that the best way to implement a “NMW Rule” is to do it on the spot. When my dentist asked me if I floss every day (I didn’t), I made the decision to start right then and there and never skip a day.
Another good way to get started is to take on some lightweight responsibility. For example, I recommend getting plants. Then you have to water them – no matter what.
If the plant dries out, you broke the rule; simple as that. The great thing is that the watering interval is usually pretty low, so there’s time to get used to it (but getting used to it you must).
If it works, you’ll enjoy the feeling of continuity. It’s like a chain of good deeds. A new habit is born.
In the past, I never had any plants. Now our apartment is full of them. I love the companionship and the continuity.
If you already have a “no matter what” rule, you have my deepest respect.
If not, whether you want to write that book, run that marathon, or just save a few bucks each month, make it work – no matter what.
2025-04-04 08:00:00
I have met a lot of developers in my life. Lately, I asked myself: “What does it take to be one of the best? What do they all have in common?”
In the hope that this will be an inspiration to someone out there, I wrote down the traits I observed in the most exceptional people in our craft. I wish I had that list when I was starting out. Had I followed this path, it would have saved me a lot of time.
If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using. I.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec.
Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written.
Great devs understand the technologies they use on a fundamental level.
It’s one thing to be able to use a tool and a whole other thing to truly grok (understand) it. A mere user will fumble around, get confused easily, hold it wrong and not optimize the config.
An expert goes in (after reading the reference!) and sits down to write a config for the tool of which they understand every single line and can explain it to a colleague. That leaves no room for doubt!
To know a tool well, you have to know:
For example, if you are a backend engineer and you make heavy use of Kafka, I expect you to know a lot about Kafka – not just things you read on Reddit. At least that’s what I expect if you want to be one of the best engineers.
As in Really Read the Error Message and Try to Understand What’s Written. Turns out, if you just sit and meditate about the error message, it starts to speak to you. The best engineers can infer a ton of information from very little context. Just by reading the error message, you can fix most of the problems on your own.
It also feels like a superpower if you help someone who doesn’t have that skill. Like “reading from a cup” or so.
Everyone gets stuck at times. The best know how to get unstuck. They simplify problems until they become digestible. That’s a hard skill to learn and requires a ton of experience. Alternatively, you just have awesome problem-solving skills, e.g., you’re clever. If not, you can train it, but there is no way around breaking down hard problems. There are problems in this world that are too hard to solve at once for anyone involved.
If you work as a professional developer, that is the bulk of the work you get paid to do: breaking down problems. If you do it right, it will feel like cheating: you just solve simple problems until you’re done.
The best devs I know read a lot of code and they are not afraid to touch it. They never say “that’s not for me” or “I can’t help you here.” Instead, they just start and learn. Code is just code. They can just pick up any skill that is required with time and effort. Before you know it, they become the go-to person in the team for whatever they touched. Mostly because they were the only ones who were not afraid to touch it in the first place.
A related point. Great engineers are in high demand and are always busy, but they always try to help. That’s because they are naturally curious and their supportive mind is what made them great engineers in the first place. It’s a sheer joy to have them on your team, because they are problem solvers.
Most awesome engineers are well-spoken and happy to share knowledge.
The best have some outlet for their thoughts: blogs, talks, open source, or a combination of those.
I think there is a strong correlation between writing skills and programming. All the best engineers I know have good command over at least one human language – often more. Mastering the way you write is mastering the way you think and vice versa. A person’s writing style says so much about the way they think. If it’s confusing and lacks structure, their coding style will be too. If it’s concise, educational, well-structured, and witty at times, their code will be too.
Excellent programmers find joy in playing with words.
Some of the best devs I know are 60+ years old. They can run circles around me. Part of the reason is that they keep learning. If there is a new tool they haven’t tried or a language they like, they will learn it. This way, they always stay on top of things without much effort.
That is not to be taken for granted: a lot of people stop learning really quickly after they graduate from University or start in their first job. They get stuck thinking that what they got taught in school is the “right” way to do things. Everything new is bad and not worth their time. So there are 25-year-olds who are “mentally retired” and 68-year-olds who are still fresh in their mind. I try to one day belong to the latter group.
Somewhat related, the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology. If they dismiss it, they can tell you exactly why, when the technology would be a good choice, and what the alternatives are.
The best devs talk to principal engineers and junior devs alike. There is no hierarchy. They try to learn from everyone, young and old. The newcomers often aren’t entrenched in office politics yet and still have a fresh mind. They don’t know why things are hard and so they propose creative solutions. Maybe the obstacles from the past are no more, which makes these people a great source of inspiration.
You can be a solid engineer if you do good work, but you can only be one of the best if you’re known for your good work; at least within a (larger) organization.
There are many ways to build a reputation for yourself:
Why do I think it is important to be known for your work? All of the above are ways to extend your radius of impact in the community. Famous developers impact way more people than non-famous developers. There’s only so much code you can write. If you want to “scale” your impact, you have to become a thought leader.
Building a reputation is a long-term goal. It doesn’t happen overnight, nor does it have to. And it won’t happen by accident. You show up every day and do the work. Over time, the work will speak for itself. More people will trust you and your work and they will want to work with you. You will work on more prestigious projects and the circle will grow.
I once heard about this idea that your latest work should overshadow everything you did before. That’s a good sign that you are on the right track.
You need patience with computers and humans. Especially with yourself. Not everything will work right away and people take time to learn. It’s not that people around you are stupid; they just have incomplete information. Without patience, it will feel like the world is against you and everyone around you is just incompetent. That’s a miserable place to be. You’re too clever for your own good.
To be one of the best, you need an incredible amount of patience, focus, and dedication. You can’t afford to get distracted easily if you want to solve hard problems. You have to return to the keyboard to get over it. You have to put in the work to push a project over the finishing line. And if you can do so while not being an arrogant prick, that’s even better. That’s what separates the best from the rest.
Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs.
The best devs don’t.
No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet!
The best keep digging until they find the reason. They might not find the reason immediately, they might never find it, but they never blame external circumstances.
With this attitude, they are able to make incredible progress and learn things that others fail to. When you mistake bugs for incomprehensible magic, magic is what it will always be.
In job interviews, I pushed candidates hard to at least say “I don’t know” once. The reason was not that I wanted to look superior (although some people certainly had that impression). No, I wanted to reach the boundary of their knowledge. I wanted to stand with them on the edge of what they thought they knew. Often, I myself didn’t know the answer. And to be honest, I didn’t care about the answer. What I cared about was when people bullshitted their way through the interview.
The best candidates said “Huh, I don’t know, but that’s an interesting question! If I had to guess, I would say…” and then they would proceed to deduce the answer. That’s a sign that you have the potential to be a great engineer.
If you are afraid to say “I don’t know”, you come from a position of hubris or defensiveness. I don’t like bullshitters on my team. Better to acknowledge that you can’t know everything. Once you accept that, you allow yourself to learn. “The important thing is that you don’t stop asking questions,” said Albert Einstein.
“In the Face of Ambiguity, Refuse the Temptation to Guess” That is one of my favorite rules in PEP 20 – The Zen of Python.
And it’s so, so tempting to guess!
I’ve been there many times and I failed with my own ambition.
When you guess, two things can happen:
Again, resist the urge to guess. Ask questions, read the reference, use a debugger, be thorough. Do what it takes to get the answer.
Clever engineers write clever code. Exceptional engineers write simple code.
That’s because most of the time, simple is enough. And simple is more maintainable than complex. Sometimes it does matter to get things right, but knowing the difference is what separates the best from the rest.
You can achieve a whole lot by keeping it simple. Focus on the right things.
The above is not a checklist or a competition; and great engineering is not a race.
Just don’t trick yourself into thinking that you can skip the hard work. There is no shortcut. Good luck with your journey.
2024-10-04 08:00:00
For the past year, I’ve been hosting the Rust in Production, a podcast about companies who shape the future of infrastructure.
This journey has taught me a lot about what it takes to create and maintain a successful podcast. Well, success is always relative; at the moment we have around 5k regular (monthly) listeners. Maybe not a ton of people, but it puts us comfortably into the top 5% of podcasts – at least by some statistics.
Whether you’re considering starting your own podcast or just curious about the process, I hope my experiences can offer some valuable insights.
Before you dive into the world of podcasting, take some time to explore the landscape. Think about branding and positioning first.
When choosing your topic, make sure it’s something you can easily generate ideas for. Try to come up with at least 10 potential episode ideas before you settle on it. If you’re planning an interview-based podcast, ensure you have a large enough network to secure at least 10 guests.
Research your competition. Listen to similar podcasts and note down what you like and dislike about them. This will help you differentiate your podcast from others in the same niche.
If a podcast is already covering your topic, that’s not necessarily a bad thing; it just shows there’s an audience for it. However, you need to find a unique angle or a different format to stand out. If you can’t be the first, be the best. Be the funniest, or the most in-depth, or the one with the most interesting guests.
Be honest with yourself about what you can offer that others can’t. If you can’t find a unique angle, it might be better to choose a different topic. If you’re not sure, ask your friends or colleagues for their opinion.
What’s the title of your podcast?
Especially the last few points are often overlooked. You want to make it as easy as possible for people to find your podcast. I’d say don’t be too clever with your podcast name. It should be easy to remember and spell. If you have to explain it, it’s probably too complicated. Also, don’t use special characters or numbers in your podcast name. It makes it harder to remember and type. Don’t pick a too generic name either. Be specific about your niche. So instead of “The JavaScript Podcast,” go for “Refactoring JavaScript” or “React Weekly.”
Don’t forget about SEO. Consider what people might search for when looking for content like yours. My podcast is titled “Rust in Production,” which is a commonly searched term. This has helped with discoverability. Another version of that, which could work, is to think about questions that people Google for. E.g. “What is functional programming?” or “How to refactor legacy code?” and then coming up with a podcast name that answers that question. For example, “Functional Programming Explained” or “Refactoring Legacy Code.”
Your podcast’s cover is equally crucial. It’s the first thing people recognize about your podcast (except for the title) before they decide what to listen to, so it needs to stand out from the crowd.
What I did was open my podcast app and look at the grid of covers.
I asked myself which ones stood out and why. I also asked a few friends and my partner to do the same. I got some great feedback that way. This visual first impression can make a big difference in attracting new listeners.
Next, decide on your podcast’s length. Fifteen minutes is great for news content, 30 minutes work well for commutes, and one hour is suitable for deep dives. Anything longer, and listeners might hesitate to commit their time.
Once you’ve done your research, it’s time to plan your content strategy. Having a regular schedule is key - weekly or biweekly episodes work well for many podcasts. Start conservatively; you can always increase frequency later, but underestimating the workload can lead to burnout.
I highly recommend buffering content by recording a few episodes before you start publishing. This gives you a cushion and reduces stress, especially when you’re just starting out.
Consider a season-based approach. For “Rust in Production,” we do 7-8 episodes and then take a break. This allows for better planning and reduces ongoing pressure.
If you’re doing an interview-based podcast, treating your guests with respect is paramount. Explain why you want them on your show in the initial email. Keep them informed about the process and be flexible with scheduling. At the start of the recording, explain how things will work and ask if they have any time constraints.
Remember, your guests are likely doing this for free. Respect their time and make the experience as smooth as possible for them.
Audio quality can make or break a podcast. Invest in good equipment - get a decent microphone and headphones, and consider ways to improve your room’s acoustics. If you’re interviewing guests remotely, consider their equipment too. A pre-call to check their setup can be invaluable, or you might even consider sending them equipment if you want consistent quality across episodes.
Always remind guests to stay close to the mic. It’s a small detail that can make a big difference in audio quality. On two occasions, I had guests who had their condenser mic backwards, and that sounds pretty dull. You get better at picking up on these things the more you record. It helps to know which way the mic should be facing (usually the logo on the mic and the volume knob should be facing you). Both guests were very grateful for the tip and the audio quality improved significantly.
One of the best decisions I made was not to edit the podcast myself. I’m incredibly thankful that Simon Brüggen agreed to do the editing for “Rust in Production.” It would have been an enormous amount of work on top of finding guests, recording, and hosting. It also helps that Simon is a Rust developer and understands the content. He can give tips on how to improve the content from a technical perspective.
For recording, tools like Zencastr, Riverside, or Descript are excellent. They capture audio on both sides, giving you uncompressed files to work with. Auphonic is great for cleaning up audio, removing filler words, and creating transcripts.
When it comes to hosting, I use Letscast. They’re not the cheapest option, but their customer service is top notch and the website is fast and not bloated.
As you progress, you’ll naturally develop your own podcasting style. For me, I prefer to let guests do most of the talking, only interjecting occasionally with questions or comments. The motto is “say less, ask more.” It’s a good rule of thumb for interviews. It’s not about you, it’s about the guest. Let them shine. In pursuit of asking better questions, I wrote an essay on how to ask better questions. I’ve also found that taking notes during recording helps me ask better follow-up questions.
Don’t be afraid to encourage your guests when they make good points. A nod, a smile, or a thumbs up can go a long way in making them feel comfortable and valued.
While it’s tempting to obsess over metrics, try not to focus on them too much. Instead, concentrate on producing content you’d enjoy consuming yourself. Be passionate about your topic and create your podcast as if no one is listening - ironically, this often leads to the most engaging content.
Starting a podcast is a lot of work, but it’s incredibly rewarding. The podcast space isn’t oversaturated yet - it reminds me of the golden age of YouTube a few years ago. Podcasting is becoming more professional now, but there’s still plenty of room for new formats and perspectives.
Remember: it’s okay to start small and grow. You’ll learn and improve with each new episode. The most important thing is to enjoy the process and share your personality with the world.
If you’re interested in Rust, consider listening to the Rust in Production podcast. I’d love to hear what you think!
