Matthias Endler

Now's The Time To Start That Blog

2026-01-26T00:00:00+00:00

I was listening to a podcast recently where someone pointed out something curious: machines have been better at playing chess than humans for three decades now, and nobody cares. People still watch human chess players. If anything, chess is experiencing a renaissance.

I don’t know anyone who wants to watch robots play chess. But I know plenty of people who love watching humans play. I’m not a big chess player myself (heck, I could hardly win any game), but I catch myself watching matches on YouTube.

The reason is that the game is way more than moving pieces on a board. There’s a background story to every player and the match is a truly human experience where people don’t only compete against an opponent but also against themselves. That’s what makes it so interesting, not the fact that there’s an algorithm which has 3646 Elo. Humans can still contribute!

And I think it’s the same with writing.

Everyone wants to read personal thoughts from real human beings, but no one writes them anymore. What we get instead is slop, and that’s hardly a good read. The moment I notice I’m reading autogenerated text, I care less.

That’s why I keep writing. My personal blog is a weird mix of ramblings about reviewing code</a>, the best programmers I know</a>, and random thoughts.

But you know what? People are reading it and from time to time I get an email from someone who found one of my articles helpful.

Time and again, when I talk to friends, they share the same experience. My friend Thomas wrote his first article about his Experience with Atlassian</a> and many people found it helpful and reached out. And even if no one does, writing is a joyful hobby and it helps me clear my thoughts.

I believe there has rarely been a better time to start writing.

Building Up And Sanding Down

2025-10-31T00:00:00+00:00

Over the years, I’ve gravitated toward two complementary ways to build robust software systems: building up and sanding down.

Building up means starting with a tiny core and gradually adding functionality. Sanding down means starting with a very rough idea and refining it over time.

Neither approach is inherently better; it’s almost a stylistic decision that depends on team dynamics and familiarity with the problem domain. On top of that, my thoughts on the topic are not particularly novel, but I wanted to summarize what I’ve learned over the years.

Source: Wikimedia</a> Public Domain </figcaption> </figure>
Building up focuses on creating a solid foundation first. I like to use it when working on systems I know well or when there is a clear specification I can refer to. For example, I use it for implementing protocols or when emulating hardware such as for my MOS 6502 emulator</a>.
I prefer “building up” over “bottom-up” as the former evokes construction and upward growth. “Bottom-up” is more abstract and directional. Also “bottom-up” always felt like jargon while “building up” is more intuitive and very visual, so it could help communicate the idea to non-technical stakeholders.
There are a few rules I try to follow when building up:

Focus on atomic building blocks that are easily composable and testable.</li>
Build up powerful guarantees from simple, verifiable properties.</li>
Focus on correctness, not performance.</li>
Write the documentation along with the code to test your reasoning.</li>
Nail the abstractions before moving on to the next layer.</li> </ul>
When I collaborate with highly analytical people, this approach works well. People who have a background in formal methods or mathematics tend to think in terms of “building blocks” and proofs. I also found that functional programmers tend to prefer this approach.
In languages like Rust, the type system can help enforce invariants and make it easier to build up complex systems from simple components. Also, Rust’s trait system encourages composition, which aligns well with that line of thinking.
The downside of the “build up” approach is that you end up spending a lot of time on the foundational layers before you can see any tangible results. It can be slow to get to an MVP this way. Some people also find this approach too rigid and inflexible, as it can be hard to pivot or change direction once you’ve committed to a certain architecture.
For example, say you’re building a web framework. There are a ton of questions at the beginning of the project:

Will it be synchronous or asynchronous?</li>
How will the request routing work?</li>
Will there be middleware? How?</li>
How will the response generation work?</li>
How will error handling be done?</li> </ul>
In a building-up approach, you would start by answering these questions and designing the core abstractions first. Foundational components like the request and response types, the router, and the middleware system are the backbone of the framework and have to be rock solid.
Only after you’ve pinned down the core data structures and their interactions would you move on to building the public API. This can lead to a very robust and well-designed system, but it can also take a long time to get there.
For instance, here</a> is the `Request</code> struct from the popular http</code> crate:`
#[derive(Clone)] pub struct Request<T> { head: Parts, body: T, } /// Component parts of an HTTP `Request` /// /// The HTTP request head consists of a method, uri, version, and a set of /// header fields. #[derive(Clone)] pub struct Parts { /// The request's method pub method: Method, /// The request's URI pub uri: Uri, /// The request's version pub version: Version, /// The request's headers pub headers: HeaderMap<HeaderValue>, /// The request's extensions pub extensions: Extensions, _priv: (), }</code></pre> There are quite a few clever design decisions in this short piece of code:

The `Request</code> struct is generic over the body type T</code>, allowing for flexibility in how the body is represented (e.g., as a byte stream, a string, etc.).</li>`
`The Parts</code> struct is separated from the Request</code> struct, allowing for easy access to the request metadata without needing to deal with the body.</li>`
`Extensions</code> can be used to store extra data derived from the underlying protocol.</li>`
`The _priv: ()</code> field is a zero-sized type used to prevent external code from constructing Parts</code> directly. It enforces the use of the provided constructors and ensures that the invariants of the Parts</code> struct are maintained.</li> </ul>`With the exception of extensions, this design has stood the test of time. It has remained largely unchanged since the very first version</a> in 2017. Source: Wikimedia</a> Public Domain </figcaption> </figure> The alternative approach, which I found to work equally well, is “sanding down.” In this approach, you start with a rough prototype (or vertical slice) and refine it over time. You “sand down” the rough edges over and over again, until you are happy with the result. It feels a bit like woodworking, where you start with a rough piece of wood and gradually refine it into a work of art. (Not that I have any idea what woodworking is like, but I imagine it’s something like that.) Crucially, this is similar but not identical to prototyping. The difference is that you don’t plan on throwing away the code you write. Instead, you’re trying to exploit the iterative nature of the problem and purposefully work on “drafts” until you get to the final version. At any point in time you can stop and ship the current version if needed. I find that this approach works well when working on creative projects which require experimentation and quick iteration. People with a background in game development or scripting languages tend to prefer this approach, as they are used to working in a more exploratory way. When using this approach, I try to follow these rules: Switch off your inner perfectionist.</li> Don’t edit while writing the first draft.</li> Code duplication is strictly allowed.</li> Refactor, refactor, refactor.</li> Defer testing until after the first draft is done.</li> Focus on the outermost API first; nail that, then polish the internals.</li> </ul> This approach makes it easy to throw code away and try something new. I found that it can be frustrating for people who like to plan ahead and are very organized and methodical. The “chaos” seems to be off-putting for some people. As an example, say you’re writing a game in Rust. You might want to tweak all aspects of the game and quickly iterate on the gameplay mechanics until they feel “just right.” In order to do so, you might start with a skeleton of the game loop and nothing else. Then you add a player character that can move around the screen. You tweak the jump height and movement speed until it feels good. There is very little abstraction between you and the game logic at this point. You might have a lot of duplicated code and hardcoded values, but that’s okay for now. Once the core gameplay mechanics are pinned down, you can start refactoring the code. I think Rust can get in the way if you use Bevy</a> or other frameworks early on in the game design process. The entity component system can feel quite heavy and hinder rapid iteration. (At least that’s how I felt when I tried Bevy last time.) I had a much better experience creating my own window and rendering loop using macroquad</a>. Yes, the entire code was in one file and no, there were no tests. There also wasn’t any architecture to speak of. And yet… working on the game felt amazing! I knew that I could always refactor the code later, but I wanted to stay in the moment and get the gameplay right first. Here’s my game loop</a>, which was extremely imperative and didn’t require learning a big framework to get started: #[macroquad::main("Game")] async fn main() { let mut player = Player::new(); let input_handler = InputHandler::new(); clear_background(BLACK); loop { // Get inputs - only once per frame let movement = input_handler.get_movement(); let action = input_handler.get_action(); // Update player with both movement and action inputs player.update(&movement, &action, get_frame_time()); // Draw player.draw(); next_frame().await } }</code></pre> You don’t have to be a Rust expert to understand this code. In every loop iteration, I simply: get the inputs</li> update the player state</li> draw the player</li> wait for the next frame</li> </ul> It’s a very typical design for that type of work. If I wanted to, I could now sand down the code and refactor it into a more modular design until it’s production-ready. I could introduce a “listener/callback” system to separate input handling from player logic or a scene graph to manage multiple game objects or an ontology system to manage game entities and their components. But why bother? For now, I care about the game mechanics, not the architecture. Both variants can lead to correct, maintainable, and efficient systems. There is no better or worse approach. I found that most people gravitate toward one approach or the other. However, it helps to be familiar with both approaches and know when to apply which mode. Choose wisely, because switching between the two approaches is quite tricky as you start from different ends of the problem.

On Choosing Rust 2025-09-26T00:00:00+00:00 Since my professional writing on Rust has moved to the corrode blog</a>, I can be a bit more casual on here and share some of my personal thoughts on the recent debate around using Rust in established software. The two projects in question are git (kernel thread</a>, Hacker News Discussion</a>) and the recently rewritten coreutils in Rust</a>, which will ship with Ubuntu 25.10 Quizzical Quokka</a>. What prompted me to write this post is a discussion on Twitter</a> and a blog post titled “Are We Chasing Language Hype Over Solving Real Problems?”</a>. In both cases, the authors speculate about the motivations behind choosing Rust, and as someone who helps teams use Rust in production, I find those takes… hilarious. Back when I started corrode, people always mentioned that Rust wasn’t used for anything serious. I knew about the production use cases from client work, but there was very little public information out there. As a consequence, we started the ‘Rust in Production’</a> podcast to show that companies indeed choose Rust for real-world applications. However, people don’t like to be proven wrong, so that conspiracy theory has now morphed into “Big Rust” trying to take over the world. 😆 Let’s look at some of the claims made in the blog post and Twitter thread and see how these could be debunked pretty easily. “GNU Core Utils has basically never had any major security vulnerabilities in its entire existence” </blockquote> If only that were true. A quick CVE search</a> shows multiple security issues over the decades, including buffer overflows and path traversal vulnerabilities. Just a few months ago, a heap buffer under-read</a> was found in sort</code>, which would cause a leak of sensitive data if an attacker sends a specially crafted input stream. The GNU coreutils are one of the most widely used software packages worldwide with billions of installations and hundreds (thousands?) of developers looking at the code. Yes, vulnerabilities still happen. No, it is not easy to write correct, secure C code. No, not even if you’re extra careful and disciplined. ls</code> is five thousand lines long. (Check out the source code</a>). That’s a lot of code for printing file names and metadata and a big attack surface! “Rust can only ever match C performance at best and is usually slower” </blockquote> Work by Trifecta</a> shows that it is possible to write Rust code that is faster than C in some cases. Especially in concurrent workloads and with memory safety guarantees. If writing safe C code is too hard, try writing safe concurrent C code! That’s where Rust shines. You can achieve ridiculous levels of parallelization without worrying about security issues. And no, you don’t need to litter your code with unsafe</code> blocks. Check out Steve Klabnik’s recent talk about Oxide</a> where he shows that their bootloader and their preemptive multitasking OS, hubris – both pretty core systems code – only contain 5% of unsafe</code> code each. You can write large codebases in Rust with no unsafe code at all. As a trivial example, I sat down to rewrite cat</code> in Rust one day. The result was 3x faster than GNU cat</code> on my machine. You can read the post here</a>. All I did was use splice</code> to copy data, which saves one memory copy. Performance is not only dependent on the language but on the algorithms and system calls you use. If you play into Rust’s strengths, you can match C’s performance. At least there is no technical limitation that would prevent this. And I personally feel more willing to aggressively optimize my code in Rust, because I don’t have to worry about introducing memory safety bugs. It feels like I’m not alone</a>. “We reward novelty over necessity in the industry” </blockquote> This ignores that most successful companies (Google, Meta, etc.) primarily use battle-tested tech stacks, not bleeding-edge languages. These companies have massive codebases and cannot afford to rewrite everything in the latest trendy language. But they see the value of using Rust for new components and gradually rewriting existing ones. That’s because 70% of security vulnerabilities are memory safety issues</a> and these issues are extremely costly to fix. If these companies could avoid switching to a new language to do so, they would. Besides, Rust is not exactly new anymore. Rust 1.0 was released 10+ years ago! The industry is moving slowly, but not that slowly. You’d be surprised to find out how many established companies use Rust without even announcing it or thinking of it as “novelty”. “100% orchestrated” </blockquote> Multiple people in the Twitter thread were convinced this is some coordinated master plan rather than developers choosing better tools, while the very maintainers of git and coreutils openly discussed their motivations in public forums for everyone to see. “They’re trying to replace/erase C. It’s not going to happen” </blockquote> They are right. C is not going away anytime soon. There is just so much C/C++ code out there in the wild, and rewriting everything in Rust is not feasible. The good news is that you can incrementally rewrite C/C++ code in Rust, one component at a time. That’s what the git maintainers are planning, by using Rust for new components. “They’re rewriting software with a GNU license into software with an MIT license” </blockquote> Even if you use Rust, you can still license your code under GPL or any other license you want. Git itself remains GPL, and many Rust projects use various licenses, not only MIT. The license fear is often brought up by people who don’t understand how open source licensing works or it might just be FUD. MIT code is still compatible with GPL code</a> and you can use both of them in the same project without issues. It’s just that the end product (the thing you deliver to your users, i.e. binary executables) is now covered by GPL because of its virality. “It’s just developers being bored and wanting to work with shiny new languages” </blockquote> The aging maintainers of C projects are retiring, and there are fewer new developers willing to pick up C just to maintain legacy code in their free time. C developers are essentially going extinct. New developers want to work with modern languages and who can blame them? Or would you want to maintain a 40-year-old COBOL codebase or an old Perl script? We have to move on. “Why not build something completely new instead of rewriting existing tools?” </blockquote> It’s not that easy. The code is only part of the story. The other part is the ecosystem, the tooling, the integrations, the documentation, and the user base. All of that takes years to build. Users don’t want to change their workflows, so they want drop-in replacements. Proven interfaces and APIs, no matter how crude and old-fashioned, have a lot of value. But yes, new tools are being built in Rust as well. “They don’t know how to actually solve problems, just chase trends” </blockquote> Talk about dismissing the technical expertise of maintainers who’ve been working on these projects for years or decades and understand the pain points better than anyone. If they were just chasing trends, they wouldn’t be maintaining these projects in the first place! These people are some of the most experienced developers in the world, and yet people want to tell them how to do their jobs. “It’s part of the woke mind virus infecting software” </blockquote> Imagine thinking memory safety is a political conspiracy. Apparently preventing buffer overflows is now an ideological stance. The closest thing to this is the White House’s technical report</a> which recommends memory-safe languages for government software and mandating memory safety for software receiving federal funding is a pretty reasonable take. I could go on, but I think you get my point. People who give Rust an honest chance know that it offers advantages in terms of memory safety, concurrency, and maintainability. It’s not about chasing hype but about long-term investment in software quality. As more companies successfully adopt Rust every day, it increasingly becomes the default choice for many new projects. If you’re interested in learning more about using Rust in production, check out my other blog</a> or listen to the Rust in Production podcast</a>. Oh, and if you know someone who posts such takes, stop arguing and send them a link to this post. How To Review Code 2025-08-06T00:00:00+00:00 I’ve been reviewing other people’s code for a while now, more than two decades to be precise. Nowadays, I spend around 50-70% of my time reviewing code in some form or another. It’s what I get paid to do, alongside systems design. Over time, I learned a thing or two about how to review code effectively. I focus on different things now than when I started. Bad reviews are narrow in scope. They focus on syntax, style, and minor issues instead of maintainability and extensibility. Good reviews look at not only the changes, but also what problems the changes solve, what future issues might arise, and how a change fits into the overall design of the system. I like to look at the lines that weren’t changed. They often tell the true story. For example, often people forget to update a related section of the codebase or the docs. This can lead to bugs, confusion, breaking changes, or security issues. Be thorough and look at all call-sites of the new code. Have they been correctly updated? Are the tests still testing the right thing? Are the changes in the right place? Here’s a cheat sheet of questions I ask myself when reviewing code: How does this code fit into the rest of the system?</li> What’s its interaction with other parts of the codebase?</li> How does it affect the overall architecture?</li> Does it impact future planned work?</li> </ul> </div> These questions have more to do with systems design than with the changes themselves. Don’t neglect the bigger picture because systems become brittle if you accept bad changes. Code isn’t written in isolation. The role of more experienced developers is to reduce operational friction and handle risk management for the project. The documentation, the tests, and the data types are equally as important as the code itself. Always keep an eye out for better abstractions as the code evolves. I spend a big chunk of my time thinking about good names when reviewing code. Naming things is hard, which is why it’s so important to get it right. Often, it’s the most important part of a code review. It’s also the most subjective part, which makes it tedious because it’s hard to distinguish between nitpicking and important naming decisions. Names encapsulate concepts and serve as “building blocks” in your code. Bad names are the code smell that hint at problems running deep. They increase cognitive overhead by one or more orders of magnitude. For example, say we have a struct that represents a player’s stats in a game: struct Player { username: String, score: i32, level: i32, }</code></pre> I often see code like this: // Bad: using temporary/arbitrary names creates confusion fn update_player_stats(player: Player, bonus_points: i32, level_up: bool) -> Player { let usr = player.username.trim().to_lowercase(); let updated_score = player.score + bonus_points; let l = if level_up { player.level + 1 } else { player.level }; let l2 = if l > 100 { 100 } else { l }; Player { username: usr, score: updated_score, level: l2, } }</code></pre> This code is hard to read and understand. What is usr</code>, updated_score</code>, and l2</code>? The purpose is not conveyed clearly. This builds up cognitive load and make it harder to follow the logic. That’s why I always think of the most fitting names for variables, even if it feels like I’m being pedantic. // Good: meaningful names that describe the transformation at each step fn update_player_stats(player: Player, bonus_points: i32, level_up: bool) -> Player { // Each variable name describes what the value represents let username = player.username.trim().to_lowercase(); let score = player.score + bonus_points; // Use shadowed variables to clarify intent let level = if level_up { player.level + 1 } else { player.level }; let level = if level > 100 { 100 } else { level }; // If done correctly, the final variable names // often match the struct's field names Player { username, score, level, } }</code></pre> Good names become even more critical in larger codebases where values are declared far away from where they’re used and where many developers have to have a shared understanding of the problem domain. I have to decline changes all the time and it’s never easy. After all someone put in a lot of effort and they want to see their work accepted. Avoid sugarcoating your decision or trying to be nice. Be objective, explain your reasoning and provide better alternatives. Don’t dwell on it, but focus on the next steps. It’s better to say no than to accept something that isn’t right and will cause problems down the road. In the future it will get even harder to deny a change once you’ve set a precedent. That’s the purpose of the review process: there is no guarantee that the code will be accepted. In open source, many people will contribute code that doesn’t meet your standards. There needs to be someone who says “no” and this is a very unpopular job (ask any open source maintainer). However, great projects need gatekeepers because the alternative is subpar code and eventually unmaintainable projects. At times, people will say “let’s just merge this and fix it later.” I think that’s a slippery slope. It can lead to tech debt and additional work later on. It’s hard to stand your ground, but it’s important to do so. If you see something that isn’t right, speak up. When it gets hard, remember that you’re not rejecting the person, you’re rejecting the code. Remind people that you appreciate their effort and that you want to help them improve. Even though you’ll develop an intuition for what to focus on in reviews, you should still back it up with facts. If you find yourself saying “no” to the same thing over and over again, consider writing a style guide or a set of guidelines for your team. Be gracious but decisive; it’s just code. Code reviews aren’t just about code; people matter too. Building a good relationship with your coworkers is important. I make it a point to do the first couple of reviews together in a pair programming session if possible. This way, you can learn from each other’s communication style. Building trust and getting to know each other works well this way. You should repeat that process later if you notice a communication breakdown or misunderstanding. “Can you take a quick look at this PR? I want to merge it today.” There often is an expectation that code reviews are a one-time thing. That’s not how it works. Instead, code reviews are an iterative process. Multiple iterations should be expected to get the code right. In my first iteration, I focus on the big picture and the overall design. Once I’m done with that, I go into the details. The goal shouldn’t be to merge as quickly as possible, but to accept code that is of high quality. Otherwise, what’s the point of a code review in the first place? That’s a mindset shift that’s important to make. Reviews aren’t exclusively about pointing out flaws, they’re also about creating a shared understanding of the code within the team. I often learn the most about writing better code by reviewing other people’s code. I’ve also gotten excellent feedback on my own code from excellent engineers. These are invaluable “aha moments” that help you grow as a developer. Experts spent their valuable time reviewing my code, and I learned a lot from it. I think everybody should experience that once in their career. From time to time, you’ll disagree with the author. Being respectful and constructive is important. Avoid personal attacks or condescending language. Don’t say “this is wrong.” Instead, say “I would do it this way.” If people are hesitant, ask a few questions to understand their reasoning. “Will this break existing workflows if we do it this way?”</li> “Which alternatives have you considered?”</li> “What happens if you call this function with an empty array?”</li> “If I don’t set this value, what will be the error message presented to the user?”</li> </ul> These “Socratic questions”</a>1</a> help the author think about their decisions and can lead to better designs. People should enjoy receiving your feedback. If not, revisit your review style. Only add comments that you yourself would be happy to receive. From time to time, I like to add positive comments like “I like this” or “this is a great idea.” Keeping the author motivated and showing that you appreciate their work goes a long way. It’s easy to miss subtle details when you look at code for too long. Having a local copy of the code that I can play with helps me a lot. I try to run the code, the tests, and the linters if I can. Checking out the branch, moving things around, breaking things, and trying to understand how it works is part of my review process. User-facing changes like UI changes or error messages are often easier to spot when you run the code and try to break it. After that, I revert the changes and, if needed, write down my findings in a comment. Better understanding can come from this approach. Code reviews are often a bottleneck in the development process, because they can’t be fully automated: there’s a human in the loop who has to look at the code and provide feedback. But if you wait for your colleagues to review your code, that can lead to frustration. Avoid being that person. Sometimes you won’t have time to review code and that is okay. If you can’t review the code in a reasonable time, let the author know. I’m still working on this, but I try to be more proactive about my availability and set clear expectations. Code reviews are my favorite way to learn new things. I learn new techniques, patterns, new libraries, but most importantly, how other people approach problems. I try to learn one new thing with each review. It’s not wasted time, if it helps the team improve and grow as a whole. Formatters exist for a reason: leave whitespace and formatting to the tools. Save your energy for issues that truly matter. Focus on logic, design, maintainability, and correctness. Avoid subjective preferences that don’t impact code quality. Ask yourself: Does this affect functionality or would it confuse future developers? If not, let it go. When reviewing code, focus on the reasoning behind the changes. This has a much better chance of success than pointing out flaws without any reasoning. Consider the following two code review comments. The first one is unhelpful and dismissive. The second suggests an alternative, links to the documentation, and explains why the change could lead to problems down the road. Which one would you prefer to receive? I realize that this requires more time and effort, but it’s worth it! Most of the time, the author will appreciate it and avoid making the same mistake in the future. There is a compound effect from helpful reviews over time. Asking is better than assuming. If you don’t understand something, ask the author to explain it. Chances are, you’re not the only one who doesn’t get it. Often, the author will be happy to explain their reasoning. Better understanding of the code and the system as a whole can result from this. It can also help the author see things from a different perspective. Perhaps they’ll learn that their assumptions were wrong or that the system isn’t self-explanatory. Perhaps there’s missing documentation? Asking great questions is a superpower.</a> From time to time, ask the author for feedback on your feedback: Have you been too harsh/nitpicky/slow/sloppy?</li> Did you point out the right things?</li> Did your feedback help them?</li> Do they have suggestions for improvement?</li> </ul> Basically, you ask them to review your review process, heh. Learning how to review code is a skill that needs constant practice and refinement. Good luck finding your own style. Thanks for pointing out that term to me, Lucca! ↩</a> </li> </ol> </section> Repeat Yourself 2025-06-23T00:00:00+00:00 One of the most repeated pieces of advice throughout my career in software has been “don’t repeat yourself,” also known as the DRY principle. For the longest time, I took that at face value, never questioning its validity. That was until I saw actual experts write code: they copy code all the time1</a>. I realized that repeating yourself has a few great benefits. The common wisdom is that if you repeat yourself, you have to fix the same bug in multiple places, but if you have a shared abstraction, you only have to fix it once. Another reason why we avoid repetition is that it makes us feel clever. “Look, I know all of these smart ways to avoid repetition! I know how to use interfaces, generics, higher-order functions, and inheritance!” Both reasons are misguided. There are many benefits of repeating yourself that might get us closer to our goals in the long run. When you’re writing code, you want to keep the momentum going to get into a flow state. If you constantly pause to design the perfect abstraction, it’s easy to lose momentum. Instead, if you allow yourself to copy-paste code, you keep your train of thought going and work on the problem at hand. You don’t introduce another problem of trying to find the right abstraction at the same time. It’s often easier to copy existing code and modify it until it becomes too much of a burden, at which point you can go and refactor it. I would argue that “writing mode” and “refactoring mode” are two different modes of programming. During writing mode, you want to focus on getting the idea down and stop your inner critic, which keeps telling you that your code sucks. During refactoring mode, you take the opposite role: that of the critic. You look for ways to improve the code by finding the right abstractions, removing duplication, and improving readability. Keep these two modes separate. Don’t try to do both at the same time.2</a> When you start to write code, you don’t know the right abstraction just yet. But if you copy code, the right abstraction reveals itself; it’s too tedious to copy the same code over and over again, at which point you start to look for ways to abstract it away. For me, this typically happens after the first copy of the same code, but I try to resist the urge until the 2nd or 3rd copy. If you start too early, you might end up with a bad abstraction that doesn’t fit the problem. You know it’s wrong because it feels clunky. Some typical symptoms include: Generic names that don’t convey intent, e.g., render_pdf_file</code> instead of generate_invoice</code></li> Difficult to understand without additional context</li> The abstraction is only used in one or two places</li> Tight coupling to implementation details</li> </ul> We easily settle for the first abstraction that comes to mind, but most often, it’s not the right one. And removing the wrong abstraction is hard work, because now the data flow depends on it. We also tend to fall in love with our own abstractions because they took time and effort to create. This makes us reluctant to discard them even when they no longer fit the problem—it’s a sunk cost fallacy. It gets worse when other programmers start to depend on it, too. Then you have to be careful about changing it, because it might break other parts of the codebase. Once you introduce an abstraction, you have to work with it for a long time, sometimes forever. If you had a copy of the code instead, you could just change it in one place without worrying about breaking anything else. Duplication is far cheaper than the wrong abstraction </blockquote> —Sandi Metz, The Wrong Abstraction</a></cite> </div> Better to wait until the last moment to settle on the abstraction, when you have a solid understanding of the problem space.3</a> Abstraction reduces code duplication, but it comes at a cost. Abstractions can make code harder to read, understand, and maintain because you have to jump between multiple levels of indirection to understand what the code does. The abstraction might live in different files, modules, or libraries. The cost of traversing these layers is high. An expert programmer might be able to keep a few levels of abstraction in their head, but we all have a limited context window (which depends on familiarity with the codebase). When you copy code, you can keep all the logic in one place. You can just read the whole thing and understand what it does. Sometimes, code looks similar but serves different purposes. For example, consider two pieces of code that calculate a sum by iterating over a collection of items. total = 0 for item in shopping_cart: total += item.price * item.quantity</code></pre> And elsewhere in the code, we have total = 0 for item in package_items: total += item.weight * item.rate</code></pre> In both cases, we iterate over a collection and calculate a total. You might be tempted to introduce a helper function, but the two calculations are very different. After a few iterations, these two pieces of code might evolve in different directions: def calculate_total_price(shopping_cart): if not shopping_cart: raise ValueError("Shopping cart cannot be empty") total = 0.0 for item in shopping_cart: # Round for financial precision total += round(item.price * item.quantity, 2) return total</code></pre> In contrast, the shipping cost calculation might look like this: def calculate_shipping_cost(package_items, destination_zone): # Use higher of actual weight vs dimensional weight total_weight = sum(item.weight for item in package_items) total_volume = sum(item.length * item.width * item.height for item in package_items) dimensional_weight = total_volume / 5000 # FedEx formula billable_weight = max(total_weight, dimensional_weight) return billable_weight * shipping_rates[destination_zone]</code></pre> Had we applied “don’t repeat yourself” too early, we would have lost the context and specific requirements of each calculation. The DRY principle is misinterpreted as a blanket rule to avoid any duplication at all costs, which can lead to complexity. When you try to avoid repetition by introducing abstractions, you have to deal with all the edge cases in a place far away from the actual business logic. You end up adding redundant checks and conditions to the abstraction, just to make sure it works in all cases. Later on, you might forget the reasoning behind those checks, but you keep them around “just in case” because you don’t want to break any callers. The result is dead code that adds complexity to the codebase; all because you wanted to avoid repeating yourself. The common wisdom is that if you repeat yourself, you have to fix the same bug in multiple places. But the assumption is that the bug exists in all copies. In reality, each copy might have evolved in different ways, and the bug might only exist in one of them. When you create a shared abstraction, a bug in that abstraction breaks every caller, breaking multiple features at once. With duplicated code, a bug is isolated to just one specific use case. Knowing that you didn’t break anything in a shared abstraction is much harder than checking a single copy of the code. Of course, if you have a lot of copies, there is a risk of forgetting to fix all of them. The key to making this work is to clean up afterwards. This can happen before you commit the code or during a code review. At this stage, you can look at the code you copied and see if it makes sense to keep it as is or if you can see the right abstraction. I try to refactor code once I have a better understanding of the problem, but not earlier. A trick to undo a bad abstraction is to inline the code back into the places where it was used. For a while, you end up “repeating yourself” again in the codebase, but that’s okay. Rethink the problem based on the new information you have. Often you’ll find a better abstraction that fits the problem better. When the abstraction is wrong, the fastest way forward is back. </blockquote> —Sandi Metz, The Wrong Abstraction</a></cite> </div> It’s fine to look for the right abstraction, but don’t obsess over it. Don’t be afraid to copy code when it helps you keep momentum and find the right abstraction. It bears repeating: “Repeat yourself.” For some examples, see Ferris working on Rustendo64</a> or tokiospliff working on a C++ game engine</a>. ↩</a> </li> This is also how I write prose: I first write a draft and block my inner critic, and then I play the role of the editor/critic and “refactor” the text. This way, I get the best of both worlds: a quick feedback loop which doesn’t block my creativity, and a final product which is more polished and well-structured. Of course, I did not invent this approach. I recommend reading “Shitty first drafts” from Anne Lamott’s book Bird by Bird: Instructions on Writing and Life</a> if you want to learn more about this technique. ↩</a> </li> This is similar to the OODA loop</a> concept, which stands for “Observe, Orient, Decide, Act.” It was developed by military strategist John Boyd. Fighter pilots use it to wait until the last responsible moment to decide on a course of action, which allows them to make the best decision based on the current situation and available information. ↩</a> </li> </ol> </section> Watching Millionaires 2025-06-06T00:00:00+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</a> where people share their stories, but you need to know where to look. If anything, we all should share more. Write about</a> 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. </blockquote> That’s from his Letter For Readmission To Harvard (2005)</a>. 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. Paolo the Plumber 2025-06-02T00:00:00+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. Reinvent the Wheel 2025-05-24T00:00:00+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: those who tried to invent a wheel themselves and know how hard it is</li> those who never tried to invent a wheel and blindly follow the advice</li> </ul> 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. </div> “What I cannot create, I do not understand” – Richard Feynman</a>, Physicist and Nobel Prize Winner </blockquote> 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: There is an infinite complexity in everyday things.</li> Building something that even a single other person finds useful is a humbling experience.</li> Humans like you created these abstractions. They are not perfect and you can make different tradeoffs in your own design.</li> </ul> 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: Build a better wheel (for some definition of better)</li> Learn how wheels are made</li> Teach others about wheels</li> Learn about the inventors of wheels</li> Be able to change wheels or fix them when they break</li> Learn the tools needed to make wheels along the way</li> Learn a tiny slice of what it means to build a larger system (such as a vehicle)</li> Help someone in need of a very special wheel. Maybe for a wheelchair?</li> </ul> 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</a>. 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. No Matter What 2025-04-13T00:00:00+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. Bad grade at school? Dinner at 6.</li> Played computer games all afternoon and lost track of time? Dinner at 6.</li> No matter how bad your day was, dinner is always waiting for you.</li> </ul> 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. The Best Programmers I Know 2025-04-04T00:00:00+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</a>, the Python Standard Library</a>, or the TOML spec</a>. 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: its history: who created it? Why? To solve which problem?</li> its present: who maintains it? Where do they work? On what?</li> its limitations: when is the tool not a good fit? When does it break?</li> its ecosystem: what libraries exist? Who uses it? What plugins?</li> </ul> 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”</a> 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: You built and shipped a critical service for a (larger) org.</li> You wrote a famous tool</li> You contribute to a popular open source tool</li> You wrote a book that is often mentioned</li> </ul> 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</a>. 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: In the best case you’re wrong and your incorrect assumptions lead to a bug.</li> In the worst case you are right… and you’ll never stop and second guess yourself. You build up your mental model based on the wrong assumptions. This can haunt you for a long time.</li> </ul> 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. So You Want to Start a (Tech) Podcast 2024-10-04T00:00:00+00:00 For the past year, I’ve been hosting the Rust in Production</a>, 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</a>. Whether you’re considering starting your own podcast or just curious about the process, I hope my experiences can offer some valuable insights. </picture> </a> The ‘Rust in Production’ podcast cover </figcaption> </figure> 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? Is it catchy and easy to remember?</li> Does it convey what your podcast is about?</li> Is the domain name available?</li> Are the social media handles available?</li> Is there a simple abbreviation you can use for hashtags or mentions?</li> </ul> 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. </picture> The grid of podcast covers in my podcast app </figcaption> </figure> 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</a> 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</a>, Riverside</a>, or Descript</a> are excellent. They capture audio on both sides, giving you uncompressed files to work with. Auphonic</a> is great for cleaning up audio, removing filler words, and creating transcripts. When it comes to hosting, I use Letscast</a>. 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</a>. 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</a> podcast. I’d love to hear what you think! Follow the Hackers 2024-09-07T00:00:00+00:00 Want to see tomorrow’s important technologies? Watch what hackers are passionate about today. I’m using the term “hacker” in the spirit of the Hacker Ethic, as described by authors like Steven Levy</a> and Pekka Himanen</a>. In this context, a hacker is someone who: Follows their passion and seeks self-fulfillment through technology</li> Creates something beneficial for the wider community</li> Values freedom, cooperation, and voluntary work</li> Challenges traditional work ethics with a focus on creativity and sharing</li> </ul> These folks are a small subset of the population, but they have some traits that make them excellent predictors of the future: They care deeply about their field - programming being just one example</li> They’re passionate about the things they believe in</li> They’d use something even if no one else cared about it</li> They work at the cutting edge, so they need the best tools to do their job</li> They hold strong opinions on what works and what doesn’t, backed by solid evidence</li> They don’t care about investors, quarterly earnings reports, or politics - they purely focus on the technology’s value</li> </ul> Of course, not every hyped technology makes it big. Remember NFTs or Web3? The key difference? Real hackers were never passionate about these technologies - ordinary people were. Another red flag is when the technology’s benefits are hard to explain. If hardcore tech people can’t explain the benefits to you, that’s a bad sign. Look deeper and you’ll find different motivations at work! It’s typically people looking to profit from technology. They brand themselves as Investors, “Serial Entrepreneurs”, and “Thought Leaders”. You’ll find them on LinkedIn, updating their profiles with the latest buzzwords every few months. While a few are legitimate, most are opportunists who couldn’t explain the technology to save their lives. Profit is their only motivation. The hackers? They don’t care what you think about them. They’ve got nothing to sell you. They’re too busy building cool stuff! A question hackers care about is “who owns the platform”? Companies always have an agenda. Pour in your time and effort, and they might lock you out to profit from your work. Hackers don’t like that.</a> Therefore, all the winning ideas I mentioned are open source. If a technology isn’t, that’s a major red flag when evaluating its future potential. It’s not even optional anymore - it’s pretty much mandatory. But there’s another reason why open source is a catalyst for success: Initially, open source projects start as minimally functional versions without user-friendly documentation. They might be tough to set up, but the core idea is there. If people stick with it despite the lack of hand-holding, you know it’s solving a real problem - and that’s a sign of a winning idea. You probably know I’m all in on Rust. After all, I make my living as a Rust consultant</a>. It took Rust over a decade of development to gain any real traction in the industry. It’s been a slow but steady climb. It takes time for the public to catch up before a technology hits its stride. For core technologies like programming languages or databases, it often takes a decade or more. That’s simply how long technology needs to mature. That’s why I tell founders to stay slightly conservative when adopting new tech. The industry needs time to catch up, and big companies need specialized tools to integrate new tech into their existing systems. On the other side, investing early in promising technologies is a calculated risk because the writing is on the wall. Hackers are already living in the future. You can use that to your advantage. Ask 10 hackers what new things they’re really excited about, and you’ll get a good picture of what’s going to be important in a few years. Most business people don’t talk to hackers regularly. That’s a fact you can use to your advantage. If you’re selling to developers (and you probably shouldn’t</a>), the key is to really listen to what the hackers are saying and then follow their lead. Be Simple 2024-09-02T00:00:00+00:00 Last night I realized that my life is very simple. That’s not by chance, but by conscious effort. Life becomes complex all by itself if you do nothing about it. One day you’ll wake up and you have a mortgage, 10 on-demand subscriptions, 20 insurances, 1000 open browser tabs, a demanding job and a dog. And when you realize it, you wonder how you got there. I keep my life simple because I know my time is limited. Time and health are my best proxies for happiness. Quite the contrary: give me enough time and I find ways to entertain myself. My friends might disagree, but I consider myself to be an introvert. I like to spend time on my own to explore and learn. There hasn’t been a boring moment in a long time. If life was more complex, that would take away my time, but time is the resource I can’t replenish, so I protect it. How? Mostly by saying NO. No streaming subscriptions. No Disney+, no Netflix. I rarely watch TV anyway.</li> No gym memberships. Just run in the park.</li> No Instagram or TikTok, but part of that is getting older.</li> My shoes are 6 years old. So is my wardrobe.</li> No meetings if possible. I’m the guy who sits at his desk for 8 hours straight, only getting up for bathroom breaks twice.</li> No property; I’m a happy tenant.</li> No commute; I work remotely.</li> </ul> Great home cinema setup you have there. Thanks for inviting me over! At home, I don’t even have external speakers. You’re planning a trip to the Bahamas? Enjoy! Send me a photo. Regarding technology, that means: Even though I’m a programmer, I only have a single screen.</li> I evaluate tools, but I keep the number of tools limited.</li> My editor doesn’t have a debugger.</li> No Notion or Obsidian if a text file + git is enough.</li> I limit the number of browser tabs with an extension</a>.</li> </ul> My goal is not to have as few possessions as possible – I own a lot – but to lead a simple life. I’ll happily buy things if they make my life simpler. The last big life improvements were a robot vacuum cleaner (four years ago) and an automated cat litter box (two years ago). If I decide to buy something, I make sure it’s the absolute best I can afford. (My rule is actually “don’t buy crap”.) For example, I spent a ridiculous amount on the best laptop I could buy. It’s my daily driver that I spend most of my time with, so it needs to be an absolute workhorse. My work is also compute-intensive, so I saw the purchase as justified. I always pay the price in full. No lease, no monthly payments. I have to use services for work, but I prefer monthly payments over yearly subscriptions, even if they are 30% more expensive. The fact that I can cancel at any time is more important to me. I know that when I buy something, it demands my attention. Maintenance is not fun. Even though I like the idea of owning something, I probably don’t truly own it. That makes me the worst consumer possible. I keep things in my Amazon basket forever. From time to time I look at the items, and when I enjoy seeing them in my basket… I keep them there. The rest, I just delete. This way, I get the “feeling” of owning things without spending any money. To live with such a person is not easy. We have regular discussions about “investing” money into things that I’m skeptical about. It takes me ages to reach a conclusion. Vacation planning is definitely one of my weaknesses. I am very well aware that my approach is not perfect at times. I am okay with making these sacrifices for protecting my time and therefore my happiness. Recently, I got a few emails from people telling me that my newsletter subscription is broken. I’m aware of that. My newsletter provider shut down. I won’t fix it. It turns out that people find other ways to follow me; either on Mastodon or via RSS. I also don’t have a comment section – Reddit or HN work just fine. Even though there are a few folks on my old newsletter list, I never got around to sending many emails. I don’t particularly enjoy writing a newsletter, so it might be best that it finally broke. I will probably remove the signup box. It would be nice to have it “just work”, but the next best thing is to not have it at all. Perhaps another way to explain it is the midwit theme: </picture> </figure> I try to stay on the left side of this curve as much as I can. I’m aware that there are “smarter” ways to do things, but I don’t want to dedicate time to learning about them. I only dedicate time to things that matter to me and that I want to go really deep into. The meme shows simple approaches on both ends, with a complicated phase in between. Getting to the right side of the spectrum takes lots of effort, and I’ve only made that journey a few times in my life. For the rest, knowing there’s an awkward complicated phase in between keeps me happily on the simple side. It’s fine. Greatness comes from dedicating time to the things that matter. The most productive people I know are focused. Yes, there’s a creative process and they allow themselves to be creative, but they do so in a very constrained environment: their office. While others chase trends, they do the thing they’re always doing. They put in the hours. It’s way easier to be focused when life is simple. When there’s no room for distractions and complexity. I find that constraints help as well. Technology is one major source of distraction. Some of the best stories were written with a typewriter. In itself, it’s a very limited environment, but it takes away all the distractions and lets you focus on the task at hand. I find that inspiring, liberating. That’s why I like constraints. When I give presentations, I wonder what I’d write if I could only have 5 slides with 5 words each, or I could only use two colors, or only show images. It keeps me focused on the message. It’s simple. Simple is beautiful. Simple makes me happy. What to Write 2024-08-20T00:00:00+00:00 People sometimes ask me how I come up with things to write. To me, it’s the same as asking how I come up with things to say. There’s always something to say. It might not be novel or interesting to most, but it’s important to me and hopefully to someone else. What people actually want to know is how to come up with something interesting to write. But why should that matter? What if people don’t find it interesting? Was it a waste of time? There’s this funny thing which happens when you write for a while: you forget what excited you about writing in the first place. Instead, you find yourself chasing trends, trying to get more views, and build a following. Even if you’re aware that this is happening, it’s hard to stop. Your inner monologue tells you that what you’re writing isn’t good enough or that your readers won’t like it. Writing becomes a chore. Eventually, you stop writing. Somewhat tautologically, people come here exactly for one reason: to read what I write. If I make it about them, I have to guess what they want to hear, which kills the joy in writing, and also, in reading, as the content becomes predictable. Interesting Doesn’t Mean Novel.</h2> Just because someone else wrote about the same topic doesn’t mean it’s off-limits. There are a million love songs to disprove that. As it turns out, while they all revolve around the same topic, they’re all unique. They are personal, which is what makes them different. Some of these songs I like because I can relate to them. To me, that’s what makes them interesting: it’s the same story but told in a different way – a personal way. And that personal makes it new and that new makes it interesting. Writing is a lot like that. I get to learn about how other people feel and how they think. It’s mostly an experience; shaped into words. It’s beautiful to think how writing is such a simple way to learn from the experiences of others. And how, with just a few words, you can emotionally connect with a stranger. It’s a very human experience. Often, what you leave out is more important than what you keep; the reader fills in the blanks. Eventually, a story starts a life of its own; when it gets shared; when it gets retold. It’s no longer the author’s story but the reader’s. It becomes part of lore. Who wrote it isn’t that important. I can’t tell who reads this and why should I care? Instead of trying to make other people enjoy my writing, I want to connect with people who like the same topics. Big difference. It gives me confidence that I will never run out of things to write. At least not as long as I remember why I write. It’s liberating because I don’t have to chase the new. Instead, whatever it turns out to be is enough. At times, I’m as clueless as the reader to see where this leads me. Maybe someone else will find joy in it, maybe not. It doesn’t matter. What matters is what you think matters, and that’s what you should write about. Move Slow and Fix Things 2024-08-15T00:00:00+00:00 Growing up as a kid in rural Bavaria, I always dreamed of moving to the US to run a startup. Many kids in my generation shared that dream. To me, it felt like the only way to combine my two greatest passions: writing code and building things. As I got older, I became disillusioned with the narrative surrounding Silicon Valley. The hockey stick growth, the VC money, the “get rich quick” mentality – it was all one big illusion. For a long time, I couldn’t put my finger on what exactly bothered me about it. Part of what made me increasingly uncomfortable was the glorification of hustle culture – the idea that you have to work yourself to the bone to make it big against all odds. </picture> </figure> The other part was the “winner takes all” mentality and the mindset that you have to “move fast and break things” to succeed. I don’t believe that has to be the case. As it turns out, I’ve always been drawn to the exact opposite: sustainable growth, robust solutions, and a long-term mindset. That’s why I’ve been contributing to open source for 15 years</a>, why I only run small, bootstrapped businesses</a> or non-profits</a>, and why I focus on writing and knowledge sharing. Paul Graham and his VC buddies would have you believe that your ultimate goal as a founder should be to build a unicorn. But when I look at the Ubers, Facebooks, and Googles of this world, I see greed, gatekeeping, systemic exploitation, user tracking, excessive resource consumption, and lawsuits against competitors. These companies will do anything in their power to stay on top – even if it means bending the law or finding legal loopholes. What kind of role model is that? Who’s on the “other side”? It’s the humble minority building small but meaningful things. These people advocate for privacy, develop civic tech, try to live within their means, move deliberately, and fix what’s broken. They fly under the radar because their success isn’t measured in dollars, and they lack big marketing budgets. Instead, they focus on their product, doing a lot with very little. I find that far more inspiring. </picture> </figure> It’s incredibly rewarding to build something people love that can provide you with a comfortable living. There’s no need to risk it all, drop out of college, work insane hours, and leave a trail of destruction in your wake. You can build something small and useful instead, without a venture capitalist breathing down your neck. It’s still hard work, but you’re leaving the campsite a little better than you found it. Note that moving slowly doesn’t mean you can’t make quick decisions. It’s just that the execution should be deliberate. Don’t wreak havoc along the way. Because the time to fix what you might break rarely comes. In “Why to Not Not Start a Startup”</a>, Paul Graham writes: So, paradoxically, if you’re too inexperienced to start a startup, what you should do is start one. That’s a way more efficient cure for inexperience than a normal job. In fact, getting a normal job may actually make you less able to start a startup, by turning you into a tame animal who thinks he needs an office to work in and a product manager to tell him what software to write. </blockquote> Let me be blunt: that’s nonsense. It paints a black and white picture of the world that simply doesn’t exist. You don’t have to choose between starting a startup and working a soul-crushing job as a “tame animal” in a cubicle. There’s a whole spectrum of possibilities in between! For instance, you could work for yourself or with a small team, making use of your creativity and coming up with your own ideas. Paul wants you to start a startup because he wants to fund you and profit from your hard work. His motives are purely egoistical. If you happen to hit the startup jackpot, Paul gets even richer and you might become wealthy too. If you don’t, you’re left with nothing while Paul, already rich, gets to write an essay about your failure. That’s a whole lot of risk for very little upside. You might wonder why I’m picking on Paul Graham so much. It’s because I once looked up to him and valued his essays. He represents a worldview I used to believe in, but now consider harmful. Most of his essays seem true on the surface, but dig deeper and you’ll find his claims are based on a narrow worldview and rarely supported by evidence. Misleading young, impressionable people is dangerous. Startup founders bear all the downside risk, while venture capitalists are well-insulated from failure. VCs spread their bets across numerous startups, ensuring they profit regardless of individual outcomes. For you, the founder, it’s an all-or-nothing gamble with your time, energy, and often your financial stability. Of course not. But I’d argue it’s becoming less and less relevant in today’s world. Take building a software product, for example. You don’t need a fortune to get started anymore. There are website builders, cloud hosting solutions, and open source software at your fingertips. Why take on VC money when you’re just starting out? Some might argue that you profit from valuable networking opportunities and business advice along with the funding. But most of that information is freely available online these days. There’s an abundance of podcasts, videos, and books on the subject if you’re willing to learn. It’s trickier, of course, if you’re building a physical product. But even that has become much easier in recent years. Could you sell a 3D printed prototype before scaling up production? Or launch a Kickstarter campaign to fund your first batch of products? There are now print-on-demand services for t-shirts, mugs, posters, and books. Plus, there are plenty of brick-and-mortar stores you could approach with your business idea if you’re looking to collaborate. Let’s say you do become wildly successful and urgently need capital to scale. Maybe then VC money is one way to go. Or you could take out a loan. Either way, remember that money always comes with strings attached. Funding might force you to do things you’re not comfortable with, like compromising your users’ privacy or your own values. And even if not, you’ll constantly be pressured to find new avenues for growth. Wouldn’t it be nicer to focus on making your product better instead? That’s often far more rewarding. But often, if you spend enough time thinking through a problem, you might find a way to prove your concept at a smaller scale. Ask yourself: What truly motivates you? Is it power, money, or fame? If so, there are more meaningful things in life. Your self-worth isn’t tied to building a unicorn. I don’t know who needs to hear this, but it’s perfectly fine to be 23 and not be a millionaire founder. If you’re a high school or college student dreaming of running a startup, know that there’s another path. Don’t sell out your moral compass for a quick buck. You don’t have to jump on the AI bandwagon just because it’s the flavor of the month. At least 144 out of 251 companies</a> from the YC W24 batch are building products with “AI”. That’s 57% of the batch. How many of them are actually doing something meaningful with it? How many will still be around in 5 years? What lasting value do these companies bring to the world? We’re accumulating a massive amount of tech debt while rewarding short-term thinking and profit over sustainability. Sure, Paul will benefit if one of them hits it big. You can read all about it in his next essay. But maybe there’s another way. Maybe it’s okay to have a small business with a loyal user base that pays the bills. Maybe you don’t need to grow exponentially. Maybe you can move slow and fix things instead. Asking Better Questions 2024-08-12T00:00:00+00:00 Recently, I realized that I mostly get paid to ask questions. As a consultant</a>, advising companies</li> As a podcast host</a></li> In calls with potential clients</a></li> </ul> The curious thing is that, like most people in a similar position, I never had any formal training in asking questions! I basically just wing it and try to get better over time. That got me thinking: What makes a good question? The other day, I reflected on that. Here’s what I came up with. Recently, we did a survey about our podcast, and someone mentioned that some questions I asked the guests were “either-or” type of questions. Q: “Do you prefer dogs or cats?” A: “Dogs.” Ouch, not a very interesting conversation! A better one might have been “What’s your favorite pet?”. It allows for surprising answers. Q: “What’s your favorite pet?” A: “Tarantula!” We have to ask ourselves what we want out of the answer, which leads me to my second observation: Or to rephrase it, “Only ask things you care about.” If you don’t care about the other person’s answer, why even ask? Ask something else you care about instead! For example, when you ask someone if they prefer dogs or cats, what are you really asking? Do you wonder if the person is nice?</li> Do you care about the logistics of owning a pet as a full-time employee?</li> Or do you rather want to hear a certain answer from the other person that happens to fit your narrative? (The obvious correct answer is “cats”.)</li> </ul> Be honest! Dig deeper into “why” you’re asking the question. If it’s one of the former two questions, get straight to the point: Q: “Are you a nice person?” A: … Q: “How do you manage having a pet if you have to work all day?” A: … It will lead to better answers. If it’s about your own agenda and you’re just looking for someone to give you the answer you’re hoping for (confirmation bias</a>): don’t. Again, allow them to surprise you! Who knows? You might learn a thing or two about your preconceptions. Which leads to… It’s very easy to slip into a role where you’re framing people, and that lets your bias speak more about you than the person you’re talking to. Be conscious about that so that you can avoid it when it happens. Q: “Why do you love X?” A: “I don’t.” Better: Q: “Tell me something you truly believe about X” A: “I believe that…” The more unique the answer, the more you learn about the person. So I would even say that a good question is one that reveals something unique about the person who answers. What is it that only they can say?</li> What is it that they have unique insight into?</li> </ul> Q: “As an expert in X, who has been in the field for 20 years, what is one thing that people always get wrong about X?” A: “People always think that X is about Y, but it’s really about Z.” Do you know the Five Whys</a> technique? It’s simple: Ask “why” five times to get to the root of the issue. Q: Are you happy with your job? A: No. Q: Why? A: It drains my energy. Q: Why? A: I have to do boring things. Q: Why? A: My boss thinks they must be done by someone. Q: Why? A: No one got around to automating them. Q: Why? A: We don’t have the skills to automate boring tasks. Aha! If they learn how to automate things, this might lead to better job happiness! That’s insightful. What’s nice is that it was a purely mechanical process. With every step, we dug deeper into the underlying question. At some point, the truth revealed itself. I love this technique. Good questions are built on top of each other. The questions themselves don’t have to be complicated. It can actually be the same question asked a few times in a row – even a child could do that. In fact, they do. A lot! This is how they learn about the world around them. As grown-ups, we should not unlearn this technique. “It’s rude to ask that.” “Don’t pry.” “Don’t be nosy.” We should relearn it! Ask follow-up questions to get to the root of things. But also! Hold the other person accountable. Q: “How can we fix poverty?” A: “I will do everything in my power to fix it.” Q: “But how?” A: “I will try countermeasures which were discussed with…” Q: “Can you give me a concrete example?” A: “…” When someone answers your question, ask yourself if the answer really covered everything you wanted to know. Often, the most interesting pieces are omitted. Sometimes on purpose. But this is the most revealing part, the part at the verge of uncertainty and insecurity and you have to uncover it to get to the heart of the matter! If you don’t do this, conversations stay shallow. Speaking of which… “Why is the sky blue?”</li> “How do people fall in love?”</li> “Are you happy?”</li> </ul> These are simple questions! But they touch on the very foundation of what we know, our perception of the world, and ourselves. The simpler the question, the deeper the answer. Answering with “I don’t know” is totally fine. The important part is to stay curious and to be genuinely interested in the answer. Sometimes, no matter what you try, there’s just nothing in a conversation. You might have ended up in that weird space where people are simply out of their depth and you turn circles. Cut the cord. Just acknowledge it and move on. Trained conversationalists do it all the time without anyone noticing. The conversation gets boring, so they just move on to the next topic. There doesn’t even have to be a transition. Q: “So, what do you do for a living?” A: “I’m a plumber.” Q: “Oh, interesting. So, what are your plans if you win?” A: … Once you notice that, you will see it everywhere. We do it all the time in our daily lives, too, for example on the phone. Just cut your losses, move on to the next topic. Similarly, if you notice that you both are really into a topic, just run with it. Pauses are powerful. Ask your question and then… wait. Just wait. Don’t fill the silence with your own thoughts or insecurities. Let the question speak for itself. If you’re truly interested in a deeper thought, you need to give people time to unpack it - for you and for themselves. If you’re not willing to wait, you’ll miss out on the best part of the conversation. We are trained to give quick answers. If someone asks you “How’s it going?”, the expected answer is “Good, you?”. People are surprised when I take a moment to answer and give them a truly honest answer, which might be deeply personal. Similarly, let people give you their quick answer first. Then wait. Often, they will stop and follow up with a much more personal answer. Use pauses to your advantage. If you look close enough, which question to ask becomes obvious. “Why are we still working on this?”</li> “Should we split up?”</li> “How do you feel after the diagnosis?”</li> </ul> You’re addressing the elephant in the room! But just because you have an obvious question, that doesn’t make it easy to ask! You might know that the question could hurt. Or that the answer is uncomfortable to handle. And yet, it’s still the right question to ask. What I noticed is that oftentimes multiple people have the same “obvious” question in mind. They are just too afraid to ask. Most people dance around the topic because they want to be polite. They don’t address problems head-on because it’s easier! The result is small talk. Especially if you get paid to ask questions, your job is to ask questions that no one else wants to ask. Often, politics, infighting, and hidden agendas make it very hard for people to break out of their role and ask the obvious question. If you’re not afraid to ask the obvious question, you will look like Houdini. Suddenly, an avalanche of follow-up questions gets unleashed. An honest, constructive conversation emerges. The thing is, just because you don’t ask the uncomfortable question, it doesn’t make the problem go away. In fact, you might make it worse in the long run. It’s easier to get it out of the way and move on! Q: Why are we still working on this? A: Actually, I have no idea. Let’s find something else. Q: Should we split up? A: Yes, I think so. Let’s talk about it. Q: How do you feel after the diagnosis? A: I’m scared. I don’t know what to do. But I’m glad you asked. The truth is hidden in plain sight. If no one dares to ask, these questions stay unanswered. The trick is to accept the answer for what it is. Don’t be mad or angry at people who honestly answer your question. Be mad or angry for not asking sooner. In the past, I would often gloss over an answer and pretend I understood it. Turns out that it was a bad strategy: In the best case, I would have missed out on a great opportunity to learn something new. In the worst case, I wouldn’t have a good question to follow up with. Funnily, I’m rarely alone with this problem. There’s usually more than one confused person in the room. So don’t be afraid to refine your question to clarify any misunderstandings. Q: “Can you explain that differently?” A: … Q: “Am I correct in understanding that you mean…?” A: … Q: “Can you give me an example?” A: … There’s an old Chinese proverb that goes like this: He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever. </blockquote> I noticed that many people who ask great questions have exceptional observation skills. They notice things that others don’t. Q: “Why are you still working here?” A: “I need the money.” Q: “Tough luck. What’s for lunch?” A: … vs. Q: “Why are you still working here?” A: “I need the money.” Q: “I noticed that you have this book on your desk. What’s that about?” A: “Oh, that’s my passion! I’m reading up on sales because I want to start my own business.” Q: “Nice! What is it about sales that you find so interesting?” A: … See how this tiny observation about a book on the desk led to a much deeper conversation? Suddenly, you’re talking about someone’s passion and dreams. You might inspire them to have more conversations with customers during work time to get some practice. If you want to improve your observation skills, come prepared. Learn more about the person you’re talking to. What are they passionate about?</li> Who’s their role model?</li> What are they doing in their free time?</li> What are they reading?</li> Which projects are they working on?</li> </ul> If you come prepared, you’ll have an easier time asking good questions. Context makes good questions obvious. Okay, you got an answer. Now what? Many people follow up with a statement about themselves. “Oh, I also like that!” “Yes, I also did that!” “Let me tell you about my experience!” “You should do this!” This shows that you’re not interested in the other person, only in yourself. Instead, what if you could only follow up with a question? Q: “What’s your favorite sport?” A: “Table tennis.” Q: “How did you get into that?” A: “My dad played it when I was young.” Q: “What’s your favorite memory of playing table tennis with your dad?” A: “We used to play in the basement. It was so much fun!” Q: “What made it so much fun?” A: “I don’t know. It was just the two of us. It was our thing.” Q: “What did you learn from your dad about table tennis?” A: “He taught me how to serve. He was really good at it.” Q: “What’s the most important thing about serving in table tennis?” A: “You have to hit the ball at the right angle. Otherwise, it’s easy to return.” Q: “What’s the most difficult angle to return?” A: “The one that goes straight to the corner. It’s hard to reach.” See how this conversation unfolded? It’s like peeling an onion. You get deeper and deeper into the topic. You learn more about the person. You learn more about the topic. Step by step, you tap into someone else’s hard-earned wisdom. Look at all the things you learned in such a short time! Their favorite sport, their childhood memories, their relationship with their dad, how to serve in table tennis, the most difficult angle to return a serve. If you had followed up with “I like that too,” you would have missed out on all of this and probably never learned about it. All just because we kept asking questions instead of making statements. Think about all the people you know. Who do you like to talk to? I bet it’s the people who ask you questions and listen to your answers instead of talking about themselves all the time. Interestingly, it’s entirely selfish to ask questions. You learn more about the other person than they learn about you. You’re in control of the conversation. I’m still not good at asking questions. I wrote this mostly as practice for myself. Maybe it helps someone else too. Here’s a summary of what I wrote: Good Questions Are Open-ended</li> Never Ask A Question If You Don’t Care About The Answer</li> Good Questions Reveal Something About The Person Who Answers; Bad Questions About The Person Who Asks</li> Good Questions Are Stacked On Top Of Each Other</li> Good Questions Run Deep</li> Let The Winners Run And Cut Your Losses Short</li> Give People Space To Think</li> Obvious Questions Can Be The Best Questions</li> If You Don’t Understand The Answer, Ask Again</li> Good Observations Yield Good Questions</li> The Best Follow-up To An Answer Is A Question</li> </ol> Don’t be mistaken! Asking good questions is hard work! You have to be present, you have to listen, you have to reflect. It helps to take mental notes while you’re talking to someone. After a while, you will get better at spotting the patterns. Asking good questions is a skill that can be learned and improved upon. Asking more questions can’t hurt along the way. So, how do you ask better questions? The Dying Web 2024-08-08T00:00:00+00:00 I look left and right, and I’m the only one who still uses Firefox. </picture> </figure> At conferences and in coworking spaces, it’s always the same scene: people using some flavor of Chrome. Sometimes it’s Brave, sometimes Chromium, most of the time it’s just Google Chrome. I find that hilariously appalling. An entire generation grew up with access to great free tools and open standards, which helped them jumpstart their careers and gave them access to excellent technology for free. Now, the world’s largest websites are owned by the same company, which also owns the world’s most popular browser and search engine. Coincidentally, they are also the world’s largest advertising company. And people are wondering why they can’t block ads on YouTube anymore. We gave it all away for nothing. Let me be the first to admit that I too am not without sin. There was a weak moment about 15 years ago when browser performance became so unbearable on anything other than Chrome that it forced my hand to make the switch. And yes, for a while, life was good and websites loaded quickly. Reluctantly, I made the switch back to Firefox after a while, because open standards and privacy were more important than a few milliseconds of loading time. I could still understand why people would use Chrome, but I was happy with my choice. Then Firefox Quantum</a> came around, and I told all my fellow developer friends about it. To me, it was the best browser on the market, and I was proud to be a Firefox user again. It was fast, snappy, and had a great add-on ecosystem. To my surprise, nobody cared. Maybe people stayed with Chrome out of habit. Performance and privacy aside, I just don’t know how people can cope with Chrome’s limited customizability. It’s hilarious to watch people with 200 tabs named “G”, “Y”, or “X” struggle to find that one document they opened a week ago. In comparison, vertical tabs on Firefox with add-ons like Sidebery</a> make Chrome look like a toy. Anyhow, Chrome. There was a time when I tried to educate people on the negative effects of browser monoculture. Okay, my mum didn’t get it, but I was more disappointed by my fellow devs. Everyone took the easy route and happily stayed on Uncle Google’s lap. At this point, I neither have the willpower nor the energy to fight back; it’s hopeless. It’s probably easier to get blood from a stone than to convince someone to switch back to Firefox. It’s so easy to switch, you won’t even lose any open tabs</a>! </picture> </figure> True, but the issues don’t stop at my front door. As an outsider, I need to live with the consequences of browser monoculture every day. Quite a few websites are unusable by now because they got “optimized for Chrome.” Microsoft Teams</a>, for example, and the list is long</a>. These websites fail for no good reason. There are positive examples, too. Zencastr</a>, for example, used to be broken on Firefox, but they fixed it.</del> Update: Zencastr is still broken on Firefox. Thanks to Randell from Mozilla for pointing that out. Their support page states that Chrome, Edge, or Brave are required</a>. They stopped supporting Firefox in February 2021 as per this blog post</a>. There’s an open ticket in the Mozilla Bugzilla</a> tracking this issue. It’s currently blocked on some other issues, but there’s progress being made. The WebCodecs API</a>, which might be related to this problem, is currently in beta and progressing through Mozilla’s release process. While it’s disappointing that Zencastr doesn’t work on Firefox yet, it’s encouraging to see that Mozilla is actively working on resolving the underlying issues. I also use Chrome for online calls, because tools like Jitsi</a> don’t work well on Firefox. Maybe it’s because of Firefox’s WebRTC support? Or, maybe it’s because of Chrome</a>: Pop Quiz: If a website wants to play out of different speakers on your system, what permission must it have? Speaker-selection permission</li> Microphone permission</li> </ol> If you answered 2, then chances are you know your WebRTC stuff well, but you’re probably on a Chromium browser. </blockquote> Because everyone and their car stopped testing their stuff anywhere else. If everyone tweaks their site for Chrome, well, of course the site will work just fine on Chrome! We find ways around Chrome’s weird quirks. More users join the bandwagon because stuff “just works” and the vicious cycle continues. I can’t blame them. It’s easier to ride a horse in the direction it is going. *Elrond voice*: We’ve been down this road before. (Okay, I was there.) We called it the Browser Wars: Netscape vs Internet Explorer. Netscape lost and Microsoft ruled over the web with an iron fist. It wasn’t fun. We had more hacks around browser limitations than actual website functionality. Parents put their kids through college by working around browser bugs for money. Microsoft tried really hard to make life as miserable as possible for everybody: Internet Explorer has introduced an array of proprietary extensions to many of the standards, including HTML, CSS, and the DOM. This has resulted in several web pages that appear broken in standards-compliant web browsers and has introduced the need for a “quirks mode” to allow for rendering improper elements meant for Internet Explorer in these other browsers. — Wikipedia</a> </blockquote> Essentially, they broke the web and we all warmed our hands on the dumpster fire. All we got in return was quirks mode. Google is smarter! They break the web, too, but they make you stand inside the fire. …says the developer who gets tracked by Google</a> every waking moment. </picture> Source: https://www.skeletonclaw.com/image/710734055173472257 </figcaption> </figure> You see, Chrome is reeeeally good at marketing. They say all the right things: We’re fast! We’re open source! We have the latest features! What they don’t tell you is that they control the narrative of the World Wide Web. They make you feel guilty for using adblockers</a> and add weird nonstandard browser features</a> because they can. Lately, the uBlock Origin team just threw in the towel and stopped supporting Chrome</a>. But did anyone decide to jump ship? I get the feeling that by now people turn a blind eye to Google’s evil practices. Unfortunately not. They all use the same browser engine</a> under the hood. Browser makers make mistakes, so this engine is not perfect. If it contains a bug and there’s no competition, that bug becomes the standard. Alternative browser engines need to implement the bug as well to support websites which depend on it. Congratulations, you switched from a browser controlled by a 2 trillion dollar company to a browser controlled by a 3 trillion dollar company. Oh, and it doesn’t run on Windows or Linux. Both Apple and Google would throw you under the bus if it made them more profit. Oh, and did you know that Google paid Apple 20 billion dollars in 2022</a> to be the default search engine on Safari? If you’ve made it this far, do yourself a favor and spend a few minutes trying Firefox. Who knows? You might just like it. Try Firefox today,</a> please? How To Sell To Developers 2024-05-27T00:00:00+00:00 One of the hardest challenges I know is how to sell to developers. This is NOT an article for developers. Today, I want to write for non-developers whose job it is to sell to developers. My goal is to help you understand how they think. We tend to be a skeptical bunch! We’re not reachable through Google ads because we use ad blockers. We expect software to be free and open source, so we don’t usually pay for it. We subscribe to a handful of services that provide a lot of value for very little cost. Everything else we build ourselves. See the problem? How do you sell to these people? Strangely enough, when developers think about starting a business, the first products they consider are often those aimed at other developers, despite there being many easier markets to sell to! We love building things so much that we try to sell the things we build to people just like us. Here’s my advice: Don’t build a product for developers.</li> Seriously, don’t build a product for developers.</li> Since you’ll likely ignore the first two pieces of advice, at least learn how to market to developers effectively.</li> </ol> Here’s the bitter truth. To sell to developers… You will have to be present in the places where they hang out.</li> You will have to invest a lot of time in community building.</li> You will have to be extremely patient.</li> There is no shortcut.</li> </ul> What if you don’t have the time or the patience? See rule 1 above. You might ask, “Why should I listen to you? Have you ever sold a product to developers?” I’ll let you be the judge of that. Here are a few products that I have built and sold to developers: This was a fun experiment during the pandemic. We sold posters of GitHub timelines. Our marketing strategy included posts on Reddit and Hacker News, and we sent free prints to a few “devfluencers.” The novelty effect and viral marketing worked well. Eventually, we sold the company to a developer agency because we didn’t want to deal with the logistics. Read more about CodePrints in this blog post</a>. I built this tool for myself because I needed it. Lychee is a command-line tool that checks for broken links in markdown and HTML files. It has become quite popular on GitHub, with companies like Google and Amazon using it. However, I’ve never made any money from it. I reached out to some companies to sponsor the project, but it was very hard to get a response or explain why they should sponsor a free tool. I wrote about making money with Open Source here</a>. This is a directory of tools for developers. It’s a side project that I started in 2015 (did I mention you need to be patient?), and it has grown to be a popular resource. Together with two friends, we sell sponsorships and ads on the site, which provides a nice side income. I think this project works because it’s not a product for developers but a product for people who build products for developers. Our customers are mostly developer advocates, developer relations folks, and marketing people who want to reach developers. Sponsoring on Analysis Tools is extremely cheap compared to other marketing channels like Google ads. On Google, you can easily spend thousands of dollars per month trying to reach developers. On Analysis Tools, you can reach them for a fraction of that cost. The basic tier is $100 per month, and for that, you get your logo on the site and in every repo. Thousands of developers visit the site every month. It’s basically a no-brainer to sponsor the site if you build a linter, a static code analyzer, or any other tool that developers use. </picture> Tools page of analysis-tools.dev </figcaption> </figure> Think of it this way: when was the last time these companies had the chance to reach thousands of developers for $100? What is the total cost of acquisition for a developer? How much would you pay for a developer to try out your tool? And still… From the companies I’ve talked to, only around 20% get it immediately. There are perhaps 30% that need a little handholding. The other 50% see it as an ad placement and want to know the click-through rate. Let me repeat: It’s not about the click-through rate. It’s about the branding and the reach. You will never reach a critical audience if you don’t start investing in the developer community. This is not a one-time thing. You need a lot of exposure until you get noticed and developers start talking about your product. If you try to fake it, you won’t get far. Devs will avoid your product like the plague and tell their friends to do the same. Your main constraint is the attention of developers! These folks constantly get bombarded with millions of products and don’t have time to evaluate them all. They stopped actively looking for new tools a long time ago. They rely on a handful of trusted sources they follow. Getting into their circle of trust is hard, and for that reason, you need to be patient and invest a lot of time into relationship building. If you can afford it, hire a developer advocate. A good one is heavily invested in open source and knows how to write for developers. At the very least, you need to be present in the places where developers hang out. So reach out to open source maintainers in your niche and see if you can collaborate or sponsor their projects. Don’t waste cash on Google ads or other traditional marketing channels. Go where the developers are. I hope this article helped someone who is struggling to sell to developers. Perhaps one of you will reach out to some open source maintainers in their niche and sponsor their projects. That would be a great outcome! There’s a plus side to all of this: once you understand that you need to invest in the developer community, you will have a competitive advantage because most other companies don’t get it. Cursed Rust: Printing Things The Wrong Way 2023-11-01T00:00:00+00:00

If you already have a “no matter what” rule, you have my deepest respect.</p>
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.</p>

The above is not a checklist or a competition; and great engineering is not a race.</p>
Just don’t trick yourself into thinking that you can skip the hard work. There is no shortcut. Good luck with your journey.</p>

If you’ve made it this far, do yourself a favor and spend a few minutes trying Firefox. Who knows? You might just like it.</p>
Try Firefox today,</a> please?</p>

Matthias Endler

Now's The Time To Start That Blog

Building Up And Sanding Down

On Choosing Rust

How To Review Code

Repeat Yourself

Watching Millionaires

Paolo the Plumber

Reinvent the Wheel

No Matter What

The Best Programmers I Know

So You Want to Start a (Tech) Podcast

Follow the Hackers

Be Simple

What to Write

Move Slow and Fix Things

Asking Better Questions

The Dying Web

How To Sell To Developers

Cursed Rust: Printing Things The Wrong Way

Matthias Endler

Now's The Time To Start That Blog

Building Up And Sanding Down

On Choosing Rust

How To Review Code

</path> </path> </svg> </a>Ask For Feedback On Your Reviewing Style</h2> From time to time, ask the author for feedback on your feedback:</p> Have you been too harsh/nitpicky/slow/sloppy?</li> Did you point out the right things?</li> Did your feedback help them?</li>

Repeat Yourself

Watching Millionaires

Paolo the Plumber

Reinvent the Wheel

No Matter What

The Best Programmers I Know

So You Want to Start a (Tech) Podcast

</path> </path> </svg> </a>Podcast Name</h3> What’s the title of your podcast?</p> Is it catchy and easy to remember?</li> Does it convey what your podcast is about?</li> Is the domain name available?</li> Are the social media handles available?</li>

Follow the Hackers

Be Simple

What to Write

Move Slow and Fix Things

Asking Better Questions

</path> </path> </svg> </a>5. Good Questions Run Deep</h2> “Why is the sky blue?”</li> “How do people fall in love?”</li>

</path> </path> </svg> </a>8. Obvious Questions Can Be The Best Questions</h2> If you look close enough, which question to ask becomes obvious.</p> “Why are we still working on this?”</li> “Should we split up?”</li>

The Dying Web

How To Sell To Developers

Cursed Rust: Printing Things The Wrong Way