Forem: Fabian Letsch

Clean Code Is a Lie

Fabian Letsch — Wed, 01 Apr 2026 22:26:59 +0000

Few books have influenced everyday software development as much as Clean Code. It taught a generation of engineers to value readability, naming, small functions, and clarity. I learned from it too, and, like many others, I tried to apply its principles wherever I could.

But the broader message behind it is often taken too far. Readability is not the main goal of software engineering. It is a tradeoff. And once a tradeoff is turned into a rule, like the book does many times, the outcomes start to suffer. Code is not automatically better because it reads nicely. Sometimes the more complex, repetitive, or unabstracted solution is the better one. Not because readability does not matter, but because it is only one constraint among many.

Everything Is a Tradeoff

If readability were the highest goal in software engineering, TypeScript would beat C++ in many cases. But nobody seriously argues that game engines, databases, rendering pipelines, or embedded systems should be written in TypeScript just because it reads more nicely. Why? Because engineering is not about maximizing readability. It is about balancing constraints.

The same is true of almost any coding principle. Avoiding duplication (DRY) within immature code can lead to wrong abstractions. Immutable data can use more memory. Reusable code can be harder to change. No coding principle is universal. Whether it helps or hurts depends on the situation.

Read It Anyway

So why is Clean Code a lie? Because clean code does not exist, only code that makes good tradeoffs, and readability might be one of them. To make things clear, I still think Clean Code is worth reading, just as many other books and paradigms are worth learning. But don't treat what the book says as laws that always apply, because they don't.

What makes someone a good engineer is not how strictly they follow one philosophy, but how well they understand the tradeoffs they are making.

Don't forget to follow me if you found this take interesting and want to see my next one!

Delivering Quality Software at Breakneck Speed

Fabian Letsch — Sat, 21 Mar 2026 23:46:25 +0000

After working at three startups, I’ve learned that the real challenge is not moving fast. It is moving fast without creating chaos. When quality drops too far, speed stops being an advantage and starts turning into tech debt, bugs, frustrated customers, and lost revenue.

Startups usually accept this trade-off. They “move fast and break things” and ship “80/20 solutions.” That is often the right business decision, especially in highly competitive markets, where you need the advantage of innovating first. But I believe teams can “move fast and break less” if they are intentional about how they work.

The problem is that many practices that improve quality also add friction. TDD, broad test coverage, and having multiple PR reviewers can all be valuable and can even save time in the long run. But in fast-moving environments, some of these investments do not pay off quickly enough. And if a team is already struggling to keep up with one reviewer, requiring two is not realistic.

So the question becomes: how do you deliver quality software at breakneck speed?

1. Short Feedback Loops

The earlier a problem is detected, the cheaper it is to fix.

A bug caught while a developer is still typing is almost free. In code review, the cost is higher. In QA, higher again. And if a customer is the one who finds it, the cost is at its peak: more process kicks in, unnecessary communication follows, the developer has to rebuild their mental model of the code, and the customer loses trust.

Thats why short feedback loops matter so much. They improve quality while actively removing overhead.

For this reason I invest heavily in tooling like strong typing, linting, and static analysis. If a problem can be detected directly in the editor, it should be.

For example, I once added a lint rule that detects when an icon is used as the only child of a button and suggests using the IconButton component instead. That moves feedback from code review or design QA directly into the editor and prevents accessibility and design issues before they ship.

2. Pragmatism

To me, being pragmatic means solving the problem in the clearest and simplest way possible.

Complexity kills both speed and quality. If code is unnecessarily hard to understand, changing it takes longer, and mistakes become more likely.

A seasoned developer has many tools in their toolbox: complex type systems, microservices, abstractions, SOLID principles, design patterns, and more. These tools are not bad, but using them is expensive. They only pay off when they actually fit the problem and when the problem is stable enough. In a greenfield project, that often is not the case. Requirements may change again next week.

The question you should always ask yourself is: “What is the simplest solution that is good enough?” not “What is the most elegant way to solve this?”

3. Clear ownership

Many quality problems are caused by ambiguity.

A typical example: someone posts in the group chat, “I found bug X.” Then what happens? Sometimes two people start looking into it. Sometimes nobody does. Sometimes everyone assumes someone else will handle it, and in the end it lands in production, moving the feedback loop even further to the right. That is wasted time, avoidable confusion, and lower product quality.

Whether it is a bug, a feature, or just something somebody noticed, if it is worth mentioning, then somebody should be responsible for driving it to the next reliable state: building it, fixing it, assigning it, prioritizing it, or explicitly deciding not to act on it yet.

This does not mean that whoever notices a problem must always solve it personally. It means they should not let it remain unowned. If ownership is handed over, that handoff should be explicit. If you cannot name the person you handed ownership to, then you did not do it properly.

Clear ownership improves quality because issues are less likely to be forgotten, and it improves speed because it prevents duplicate work.

4. Automation

Software drifts unless something pushes back. Standards fade, steps get skipped, and “we usually do it this way” slowly turns into inconsistency.

That is why I do not put too much trust anymore in rules that live only in documentation, PR review reminders, or team habits. If a rule is not enforced, it is only a suggestion. And suggestions do not survive pressure.

Automation is powerful because it does more than save time. It fights entropy. It turns standards from something people should remember into something the system consistently enforces.

This is why I like linters, CI checks, and static analysis tools. They enforce standards reliably: dead code gets removed, IconButton gets used for icon-only buttons, and referenced translation keys must exist.

I also like AI code reviews as an additional layer in pull requests. They are less deterministic than lint rules or CI checks, but they can still catch suspicious patterns, missing context, and edge cases that humans might miss.

Conclusion

Quality and speed are not enemies, but they do require trade-offs. In fast-moving environments, you rarely get quality and speed from heavy engineering processes. You get them by making quality cheap to enforce.

For me, that comes down to four things: shortening feedback loops, being pragmatic, creating clear ownership, and automating what should not depend on memory or discipline.

Don't forget to follow me if you want to receive my next post :)

AI Made Me Hate My Job… Then I Found New Joy

Fabian Letsch — Sat, 07 Mar 2026 23:02:21 +0000

A few weeks ago, we had a regular company meeting. Nothing dramatic, until my boss said: “We should use way more AI for software development. We need to speed up.”

It makes sense. I get it.

Still, I felt this heavy drop in my stomach. I was afraid that AI would replace the part of me that loved this job.

Because I absolutely love to write the code myself! I love the struggles, thinking the solution through, finding all the places I have to consider, and then, at the end, feeling like Einstein himself when it’s finally working.

Also, AI does so many stupid things: It forgets to update related files. It “helpfully” invents patterns inconsistent with the codebase. It tries to complete the task, but it doesn’t realize when the task itself doesn’t make sense. It writes plausible tests that assert the wrong behavior. The ways AI can mess up are infinite!

People Don’t Pay for Code. They Pay for Outcomes.

And yet… on a good day, it saves me hours, and honestly, people do not pay me for being someone who codes or for having fun at work. The customer pays me for solving their needs. Management pays me for building a product that sells.

I started to notice a subtle resentment building up. I could see the direction clearly: less time for careful thinking, less pride in the craft, more pressure to “just ship,” and my role drifting from builder to operator.

For the first time in years, I caught myself thinking: If this is the future of my work, will I still want to do it?

Onto a journey to find Joy

I was recently on vacation and had time to step back and think. I realized that if AI is going to handle most of the actual coding, then there must be other things that can be fun, I mean my colleagues who do not code at all seem to enjoy their work. So I decided to look for the things that make me enjoy my work besides coding, and I found plenty!

Joy #1: Solving Real Problems for Real People

Taking ownership in not just the code, but the product you are building puts you right back at the driver’s seat. Helping someone, clarifying what they truly need, and shipping something that makes their day easier still feels deeply satisfying. And it’s meaningful to challenge assumptions, because it actually makes a difference to build the right thing, even if you are not building it by hand.

Joy #2: AI Craftsmanship

I always thought that using AI means my own acquired knowledge and craftsmanship just was replaced, but in actuality it also is real craftsmanship to use AI well. Instead of trying to be better at my original craft, I can instead try to become better at producing with AI. I can gain knowledge and experience in setting constraints, feeding it the right context and giving it the right tools. If AI is going to stay, then I better become one of the best at using it.

Joy #3: Ensuring Quality

AI can write a lot of wrong code really fast. It can make wrong architecture decisions or write something in a thousand lines when it shouldn’t be more than a hundred. That’s why I’ve started finding joy in quality ownership. One way to do that is going through a proper research and planning phase with the AI, asking it for solution proposals and then making an implementation plan together. Another is to do proper code reviews, catching issues early before the customer has to. As a German, I’ve always resonated with the craftsmanship mindset: precision, reliability, and doing things right even when nobody is watching.

Conclusion

AI increased my throughput, but it also changed what feels meaningful and enjoyable about my work. I’m learning to shift my identity from “writer of code” to “builder of product outcomes” and this can also be a lot of fun.

The joy didn’t disappear. It changed its location.

If you enjoyed this post, don't forget to follow me. Thank you for reading :)