Fabian on Software Engineering

Tailwind is Great. Tailwind Sucks.

Fabian Letsch — Sat, 30 May 2026 00:00:00 GMT

I’ve seen Tailwind dismissed as unreadable garbage and praised as the best thing since sliced bread. After three years of professional use, I think both sides are equally right and mostly talking past each other.

The opposition is often arguing based on taste: developers look at a wall of utility classes and get a funny feeling in their stomach. And yet, advocates rarely make a convincing case for why that discomfort is worth it. There are many good pro and contra arguments for Tailwind and I think both camps could benefit by putting emotions aside and acknowledging its trade-offs.

I reach for it when it fits, and leave it when it doesn’t, and I think you should, too. I’ll share how to tell if it’s the right call, but let’s first go through the pros and cons of Tailwind to establish a baseline.

What’s so good about Tailwind

Locality of Behavior

Imagine you’re buying groceries, and you want to know the price of an item. With conventional CSS, the price would be on a shelf tag, hopefully fairly close to the product. You have to look at the item, then look somewhere else to get the information you need.

Tailwind takes a different approach: the price is printed directly on the packaging. If you look at the item, you immediately know everything you need to know about it, no second location required.

The engineering principle applied here is called locality of behavior.

Tailwind allows you to style elements directly in your markup, so you don’t have to dig through stylesheets or jump between CSS and HTML sections, which can be confusing and time-consuming, even if they’re in the same file.

Naming no more

Phil Karlton once said: “There are only two hard things in Computer Science: cache invalidation and naming things.”

Thankfully, CSS itself doesn’t mess with caching, so there is nothing to invalidate. It however involves lots of naming when applying classes to elements, forcing you to pretend that a box added purely for presentation is a concept worthy of a meaningful name. Consider this example:

<div class="field">
    <label class="field__label">Search</label>
    <!-- What should we name the following div? -->
    <div class="???">
        <input class="field__input" />
        <svg class="field__icon">...</svg>
    </div>
</div>

There is no value in naming the div with the question marks. In fact giving it a name somehow implies that it is meaningful, but in reality it just exists to add some flex properties.

With Tailwind you can sidestep this waste of time and brain-power. Since the classes in Tailwind are the styles, there is nothing left to invent. Just apply the utility classes you need and move on.

Natural Consistency

Tailwind makes consistency easier than regular CSS by giving you a predefined token system for spacing, typography, colors, shadows, border radius, and more.

Using p-4, rounded-lg, or opacity-75 feels natural because they’re the defaults. Going off script with something like p-[5px] is possible, but it feels wrong. That little bit of friction is what keeps people and coding agents aligned without blocking them, naturally reducing drift.

Zero Specificity Headaches

Using Tailwind, most of the time you won’t have to deal with CSS selector complexities, including specificity. You don’t have to mess with ids, nested selectors, nth-child or element selectors, as Tailwind only uses classes for everything and classes all have the same specificity.

And if you use tailwind-merge, then you can reduce the ambiguity of “What class will be applied here?” as well, as you can ensure that always the last class that is mentioned for a given property is applied:

twMerge('text-md text-sm text-lg text-xs'); // text-xs will be applied as it is the last one.

Minimal Production CSS

Tailwind keeps your production CSS minimal. Its build process scans the codebase for used Tailwind classes and removes any it didn’t find from the final bundle. This reduces the output drastically for most projects, going down from multiple megabytes of tailwind classes, to a few kilobytes.

What Sucks about Tailwind

Classes, Classes, Classes, Src, Classes

I mentioned earlier how convenient it is to read the price right off the item. That works beautifully for just a price. But in reality, HTML elements are packed with more information. Tailwind classes and div-soup can suffocate important attributes in your markup like alt, src or aria-label and make it an unreadable mess, turning the beloved locality of behavior into a locality of noise.

// Is this image lazy loaded or not?
<img src="organic-chicken.jpg" alt="Free-range organic chicken"
className="block w-full h-48 md:h-64 object-cover rounded-t-xl
border-2 border-amber-300 bg-white p-0.5 shadow-lg hover:shadow-2xl
hover:scale-105 transition-all duration-200 ease-out dark:border-amber-600
dark:bg-gray-800" loading="lazy" decoding="async" />

It’s Complex And Inconsistent

Tailwind promises to reduce cognitive load, but actually introduces lots of it. The upfront learning curve is steep.

One would wish that they just used CSS namings for everything, but they instead named line-height leading and letter-spacing tracking.

But Tailwind doesn’t stop with weird namings. They also introduced things like square bracket syntax for arbitrary values (p-[5px]), negative prefixes that look like CLI flags (-mx-4), bang-syntax for !important (!font-bold), and magic group and peer modifiers that force you to tag parents or siblings to react to their state. All of these features are useful and important, but every one of these is its own micro-syntax you have to memorize, turning what should be simple styling into a sea of additional complexities you have to learn.

It’s a Leaky Abstraction

People getting into Tailwind often think they’ll never write style="" again. That is sadly not true. There are plenty of situations where using classes simply isn’t possible. For example, the Tailwind compiler only ships classes it actually sees in your codebase, so a dynamic class like h-[${elementHeight}px] won’t work. You’re forced to reach for the style attribute, or worse, a safe-list workaround where you maintain a string with all the possible values it could have, just to trick the scanner:

// h-[1px], h-[2px], h-[3px], h-[4px], ...

And it also isn’t up-to-date with the newest CSS features.

At the bottom of this post you can find a scroll-driven “Copy link” button animation that, at time of writing, only works in Chromium-based browsers. If I had used Tailwind, I would have had to write a plugin or custom CSS, to get this behavior, dealing with additional complexities or leaving the benefits of the abstraction behind.

Dependency Overhead

You will probably not just install tailwindcss and @tailwindcss/vite, but also packages like tailwind-merge or @tailwindcss/typography.

Tailwind comes with dependencies. This probably isn’t a big deal for you, but maybe it’s a good idea to have fewer dependencies if we have a new npm worm like every two weeks.

Build Step Required

Tailwind needs a build step. Now, if you work with something like React, then this will be a non-issue. But let’s say you are working in a weird web-page builder plugin inside Wordpress and you are editing some markup directly. Using Tailwind wouldn’t work in that environment without introducing other major drawbacks.

When to use Tailwind

All in all I don’t think Tailwind is perfect, but I also don’t think it’s bad. There are situations where its use is valid and there are situations where it isn’t. Now that we’ve got the pros and cons out of the way, let’s talk about when to use it.

Prerequisites

A few preconditions should be met before I would even consider it.

Being able to have a build step is mandatory, because otherwise you will have to ship the entirety of Tailwind, which for newer versions isn’t even possible and older versions require like ~3 Megabytes of CSS. For comparison: this whole site including HTML, CSS, Javascript and images is less than 300kb.
Being able to create components is very helpful, which means you want to be using a framework like React, Vue or Astro. Without access to components, you will end up either copying a lot of classes, breaking the engineering principle “Don’t Repeat Yourself”, or you will end up breaking the Tailwind philosophy and creating classes like btn or input, which basically nullify most of the benefits of using Tailwind in the first place.

Speed > Perfectionism

This site doesn’t use Tailwind. The main reason for that is that i am over-engineering it. This is neither sane nor necessary, but this website represents me and the values i hold and i dearly love good UX, good quality and good performance.

I am using many weird features: scroll animations, variable media queries, a weird old monitor overlay, uncommon CSS selectors… All of this is possible to some extent with Tailwind, but it would feel like trying to thread a needle while wearing gloves. It’s possible, but I would much rather do it bare-handed.

Now if you are not like me, and you do normal stuff while simultaneously trying to deliver results quickly, then Tailwind would probably be the better choice for most situations because not having to name things and also not having to find related styles to your markup saves a lot of time, even if the messiness is a real pain.

Team Work

I think teams, especially big ones, should also consider using Tailwind. As stated earlier, it naturally leads towards consistency, which is a bigger challenge, the bigger the team and product gets. Tailwinds limited options are a major blessing in such an environment.

Conclusion

Tailwind isn’t a hero and it isn’t a villain. It’s a trade: noisy markup in exchange for speed and consistency. Use it if that trade makes sense under your constraints, but don’t force it if it doesn’t. The best tool is the one that fits the job, not the one that fits your identity.

I’d genuinely love to hear your thoughts. Please drop your feedback on daily.dev, LinkedIn or Mastodon!

Linters: The Most Underabused Tool In The AI-Slop Era

Fabian Letsch — Wed, 15 Apr 2026 00:00:00 GMT

If you are generating a lot of code with AI and nobody on your team is actively maintaining your linting rules, you are wasting review time and slowly letting AI-generated garbage creep into your codebase.

AI is fast. Ridiculously fast. It will generate components, utilities, hooks, tests, whatever you ask for, in seconds. But it’s also inconsistent. It ignores conventions, reinvents patterns, and subtly drifts over time. Even when it’s “good,” it’s not reliably aligned with your codebase.

And code review? It simply cannot keep up with that pace.

So you need something that pushes back. Not sometimes. Not when a reviewer catches it. Every time.

You need linters.

Use Linters For More Than Parentheses or Quotes

There’s a simple rule of thumb:

If you can describe a problem precisely, you can probably enforce it with a linter.

I’ve implemented a lot of custom lint rules across different projects. And the pattern is always the same: anything that keeps showing up in reviews can usually be automated away.

Let’s start with a category that you might not think of when it comes to linting.

Translations & i18n

If you have JSON or YAML translation files in your codebase, then you will know the following problems:

Translation keys get referenced that don’t exist
Strings get hardcoded directly into the HTML
Translation keys accumulate over time that are not used anymore
Formal and informal pronouns are mixed in languages like German or French (“Du” vs “Sie”)

The result?

Inconsistent UX
Broken translations in production
Endless, repetitive review comments
A file with 5000 lines that could be half the size if you would just know which keys are used and which aren’t.

All of this is preventable with a linter.

What good lint rules can enforce

Tone consistency in translations.
You can scan translation files and forbid specific phrases. If your product uses “Sie,” then “Du” becomes a lint error.

Or hardcoded user-facing strings. Write a lint rule to prevent untranslated code.

Bad:

<p>Welcome back</p>

Good:

<p>{t('welcome_back')}</p>

A linter can flag every hardcoded string in templates and force everything through your translation layer, even aria-label, title, and alt.

Also invalid translation keys.
You can statically verify that keys actually exist.

t('dashboard.welccome'); // typo

This should fail immediately, not in production, not in QA.

Enforcing Specific Imports

Another subtle problem: having multiple ways to do the same thing. Imagine you’re using lodash in your project, but you’ve also implemented some of its functions yourself for one reason or another.

// ❌
import { debounce } from 'lodash';

// ✅
import { debounce } from '@/utils/debounce';

Both are technically valid, and imports rarely get much attention in code reviews, so the wrong one tends to creep in over time.

AI will usually pick whichever option it has seen more often, or just make up something that looks reasonable.

But with a linter, you can ban specific imports. And with autofixers, you don’t even have to rely on developers to correct them manually.

Other High-Leverage Rules

Once you think about it, opportunities are everywhere:

Ban entire libraries (e.g., moment)
Enforce architectural boundaries
→ Nothing in shared/ can import from features/
Enforce domain-specific naming
→ Import icons from the icon library reliably with the ...Icon suffix.

You should be creative with this. Think about what problems you have regularly.

And then you can even task LLMs to write the rules for you. They are exceptionally good at it, as linter rules are isolated from the rest of the codebase.

The Antidote for Curser & Entropyc (Puns Intended)

You might argue that you are using AI code reviews to solve these issues. And I agree, you should absolutely configure automatic AI code reviews and also build a proper agentic engineering setup. These things help. A lot.

But AI does not follow its prompts 100% of the time, no matter how good the prompt or context.

Linters are different. They either pass or fail. Every time.

Therefore, I highly suggest to go all-in on both. AI code reviews with custom prompts are especially powerful when your expectations are easy to explain, but hard to express in code.

Why have only one silver bullet if you could have two?

Conclusion

Linters won’t replace engineering judgment.
They won’t replace code reviews. (Human & AI)

But they will eliminate entire categories of problems before they ever reach review.

And that’s the point.

If you’re using AI heavily and not evolving your lint rules alongside it, you’re choosing to fight the same problems manually, over and over again.

Or you automate them once, and move on.

Bonus: Configuration Best Practices

If you hate linters, you might have configured them wrong.

The rule is simple: fix issues where they happen, not later.

Linters belong in your editor, including autofixes on save. If AI writes code, it should follow the same rule and lint immediately. Anything else is delayed feedback. Make sure not to run the linter on the entire project here, just the related files.

Pre-commit and pre-push hooks sound useful, but they often punish fast workflows. Frequent commits are a good thing, so they shouldn’t become painful.

The CI in pull requests should run the linter as well. This is your safety net for anything that was overlooked locally.

Get this right, and linting fades into the background. Fast, predictable, and just doing its job.

I’d genuinely love to hear your thoughts. Please drop your feedback on daily.dev or LinkedIn!

Clean Code Is Dangerous

Fabian Letsch — Wed, 01 Apr 2026 00:00:00 GMT

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 try to apply its principles if I can.

But the broader message behind it is often taken too far. Readability is one important goal in software engineering, but it is not the only one. It has to be balanced against other constraints. Once that balance is turned into a rule, as the book often encourages, the outcomes can start to suffer. Code is not automatically better just 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.

To be clear: I care deeply about readable code. I try to write good, readable, and easily comprehensible code every day. But treating readability as the highest goal, rather than as one factor among many, leads to poor decisions.

Everything Is a Tradeoff

Readability trades off against other constraints. One of the most important is time. Consider a function with 20 lines. You could split it into four sub-functions of 5 lines each to make it more readable. But doing so takes time. In most cases, that is a good investment: we read code more than we write it, so the upfront cost pays off later. But what if the code is just a verification script or a one-off codemod that will be deleted after running once? Then spending extra time on readability is a poor tradeoff.

Readability also trades off against performance. In React, useCallback and useMemo add noise and reduce readability. If readability were the highest goal, you would never use them. But they are sometimes necessary to make React perform well. Removing them for the sake of cleaner code would hurt the user experience.

Or take DRY (Don’t Repeat Yourself), one of Clean Code’s core principles. Follow it too strictly, and you abstract too early. You pull code into a shared function to avoid duplication, even though the two use cases will later diverge. Now your abstraction becomes technical debt. The right choice is not to eliminate all duplication, but to wait until the abstraction is clear and stable.

The same is true of almost any coding principle. Immutable data can use more memory. Reusable code can be harder to change. Small functions can obscure the overall flow. No coding principle is universal. Whether it helps or hurts depends on the situation.

And ultimately, your most important job is not writing readable code, it is creating business success. Your manager cares about delivering value that can be sold. Your customers care about the problems you solve, not whether your code is properly abstracted and well named. Doing those things well takes significant time, time that might be better invested elsewhere to create business impact.

This does not mean you should write sloppy code. Short-term business pressure versus long-term maintainability is itself a tradeoff. Rushing features out the door with poor code quality will slow you down later. But obsessing over perfect abstractions and pristine naming while missing deadlines and losing market opportunities is equally harmful.

Read It Anyway

So why is Clean Code dangerous? Because it presents engineering tradeoffs as moral absolutes. The book does not just teach techniques, it judges you for not using them. If you do not follow its principles, you are doing bad, sloppy work. That framing turns situational decisions into a test of your professionalism, and it pushes engineers toward dogmatic thinking rather than contextual judgment.

The techniques themselves are valuable. Small functions, clear naming, removing duplication, these are useful tools. But there is no such thing as universally “clean” code, only code that makes the right tradeoffs for its context.

I still think Clean Code is worth reading. Learn the techniques. Understand the reasoning. But treat the book as a collection of useful patterns, not a moral framework. Apply the ideas where they make sense. Ignore them where they do not.

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

I’d genuinely be interested to hear your thoughts. Please drop your feedback on daily.dev or LinkedIn! <- This is not marketing talk, I actually care!

Delivering Quality Software at Breakneck Speed

Fabian Letsch — Sun, 22 Mar 2026 00:00:00 GMT

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 linter 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 linter 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.

Do you know other ways to ensure quality while staying fast? Please let me know on daily.dev or LinkedIn.

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

Fabian Letsch — Fri, 27 Feb 2026 00:00:00 GMT

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.

Have you gone through the same process? Are you excited or scared about the future of software development? I would love to hear about it on daily.dev or LinkedIn.

Beating Distractions: A Survival Guide

Fabian Letsch — Sun, 12 Oct 2025 00:00:00 GMT

Lets be real, its way too easy to spend your “work” day jumping between social media, news, daily.dev, YouTube and reddit. If you’re anything like me, it’s tempting to tell yourself that learning new things is the same as actually getting work done.

I have spent many years trying to beat this, but on my own i never really succeeded. Then i found the following tools and since then, its way easier:

Cold Turkey Blocker

Cold Turkey Blocker blocks sites across all browsers and blocks desktop apps and games as well. It lets you set timers during which you cant unblock it. The best part? Its smarter than you are: change your system time? Nope. Kill the process in Task Manager? Good luck. Its stubborn, and thats exactly what I needed, and you might too. I HIGHLY recommend it!

onesec App

For your phone, onesec is a genius little app. Whenever you try to open a distracting app, it throws up a long, unskippable screen. You have to wait a few seconds before you can proceed, which is just enough time to realize that you dont actually want to go there.

Phone Lock Box

The easy solution would just be to put your phone in the next room, but if that doesnt work for you, this one might help: put your muted phone in a lockbox and set a timer – No notifications, no doomscrolling, just you and your work. 🫠

If you’re battling the same distractions, start with one tool and one habit, and give it a week. Small changes add up fast and future you will thank you.

What are your secret weapons against distractions? Please let me know on daily.dev.

Do Your Comments Help or Hurt?

Fabian Letsch — Thu, 02 Oct 2025 00:00:00 GMT

Have you ever seen a stop sign with another sign below it that says, “This is a stop sign”?

…

No, me neither.

Yet, step into any codebase and you’ll trip over comments doing exactly that:

The Department of Redundancy Department strikes again!

Now, maybe you’re thinking, “Hey, it’s just some harmless noise.” Sure, but don’t get too comfortable, because i have a whole bunch more!

1. Lies, damned lies and Comments

Comments sometimes are like politicians: they promise one thing and deliver another. Maybe someone updated the function but forgot about the comment, or they just copy-pasted without updating it.

No matter what is the cause: The comments might lie, the code will not.

2. TODO or NOT TODO, that is the question

Do you know the situation where you leave something in the back of the fridge and months later it’s still there, completely spoiled, and you pretend not to see it? // TODO: Refactor this. is the digital equivalent of exactly that.

Adding those TODOs while developing is fine; But merging a pull request littered with TODOs? Nah. Do your team a favor: turn TODOs into real tasks in your project management tool and actually assign them. But beware because in task management land a place called “Backlog” exists, which is a synonym for “Graveyard”.

Speaking of graveyards…

3. Comments Are Not a Code Graveyard

Commented-out code just clutters the codebase. If you’re not using code anymore, delete it. You can always find old versions in the Git history if you need them. In nine years as a developer, I’ve rarely had to recover old code from comments.

So then what does a useful comment look like?

Practical Tips for Writing Good Comments

1. Do not write the comment in the first place

Whenever you think you will need a comment to explain what is happening, pause. Can you clarify the code? Comments become unnecessary when the code itself tells the story.

2. Explain the Why, Not the What

The computer cares about what the code does. Your fellow developers care about why you made it do that weird thing. If you had to pick a workaround for a browser bug, or hack something to work around an API quirk, write that down.

Do not do this:

// Wrapper div is needed

Do this instead:

// Wrapper div is required for Firefox, see: https://bugzilla...

3. Reference Issues and Tickets directly

Link to relevant issues, Jira tickets, or merge requests right in your comment. This gives context and traceability.

// Some users don't have an id... Why? See issue: #756
if (!user.id) {
    // handle missing id
}

That way, when someone’s looking through the code six months later, they will not end up deleting something that is actually needed or asking you why its there.

4. KEEP IT SIMPLE, STUPID

Nobody is going to read a novel in a code comment. If you need more than a couple of lines, consider if the information should go elsewhere, such as developer documentation or a linked issue.

Write simple code that speaks for itself, comment only to explain the why and don’t litter the code with TODOs nobody will tackle.

Is there more to say about comments? Please tell me on daily.dev.

Being "Smart" Is Painful

Fabian Letsch — Thu, 25 Sep 2025 00:00:00 GMT

Look At This Marvel:

With this you will never have to import type { ButtonProps } from './Button' ever again! Just import { Button } from './Button' and voila! Component <Button /> and Props Button.Props are right there.

Isn’t it smart?

…

Well yes it is and that is exactly the problem!

You see, in software development SMART usually means COMPLICATED and if i have learned anything over the years it is that COMPLICATED means BAD.

And this code is smart and complicated for so many reasons!!

1. You Hardly Ever Import Props Directly

Seriously, how often do you actually need to import the props from outside the component file? Maybe twice a year? Forcing every file to bend to this “smart” import logic is like carrying an umbrella every day because it once rained in 2017.

2. Every Developer And Their Mum Will Ask “Why?”

Yeah, it’s clever. For about 5 minutes. Then you realize nobody will remember two months from now why the Button has a mysterious namespace. “Props” isn’t just a type anymore, it’s an easter egg with a riddle.

3. Weird Edge Cases

Have you tried assigning namespaces to an object?

Well lets keep this short, it doesn’t work. So when you ever run into this, you will have to solve this in an even more complicated way… Congrats!

4. Even LLMs don’t get it

As this code is unusual LLMs will not get it and will definitely not start writing it themselves unless you add a rule for it. Just like devs, LLMs work better with what’s idiomatic. (Idiomatic means: Code that follows the patterns that people are used to.)

As Grug once said “complexity very, very bad”

The truth is, the best devs don’t add complexity, they remove it. Being able to write smart code, but then not doing it. That is true wisdom. With smart code you will get: More bugs, more questions, more dependence, more confusion, more time spent reading code and more time spent explaining your idiocy to LLMs…

Let my pain be your warning! Do yourself a favor and write your Props the boring way. In fact, write all your code the boring way. Your future self will thank you!

Have you been “Smart” before? I’d genuinely love to hear about it on daily.dev.