A developer can ship a perfectly functional product and still make something that feels wrong.
That's probably one of the strangest things about software.
The button works. The API is fast. The layout is responsive. The animation is hardware-accelerated. Everything is technically fine.
And yet, you open it and immediately think: something is off.
I think that something is taste.
Taste starts with being able to tell
I don't think taste is some mysterious creative gene that designers are born with.
It's much simpler than that.
If you can look at two interfaces and tell me that one is better than the other, you've already started developing taste.
The interesting part comes next:
Why?
Why does one feel calmer?
Why does one feel easier to understand?
Why does one interaction feel satisfying while another feels slightly annoying?
That's where taste starts becoming useful.
You start noticing things you didn't notice before.
The spacing. The timing. The hierarchy. The amount of information on a screen. The way something responds when you click it.
You don't necessarily know the rule yet. You just know that one feels right.
And that feeling is usually not coming from nowhere.
You are already learning taste
You don't develop taste by reading a list of design principles.
You develop it by seeing things.
A lot of things.
You use an app every day. You notice how its navigation works. You notice how quickly a menu opens. You notice that a button is exactly where your thumb expects it to be.
You use another app and suddenly the same thing feels awkward.
Most of this happens without you consciously thinking about it.
We've spent years staring at screens. Hours every day. Hundreds of products, interfaces, buttons, menus, transitions, empty states, loading indicators, keyboards, notifications.
Our brains are constantly collecting these patterns.
That's why something that would have felt completely normal ten years ago can feel strangely outdated today.
The interface didn't necessarily become wrong. Our reference point changed.
Taste moves because the things around us move.
Study what you already like
This is where I think taste becomes a skill rather than just a preference.
When you find something you genuinely like, don't just save it.
Study it.
Why is that spacing this large?
Why does this animation exist?
Why does the interface give me feedback here but not there?
Why does this product feel simple when you know the underlying problem is complicated?
You start taking apart things that already feel good to you.
And slowly, you build a mental library of patterns.
Emil Kowalski makes a similar argument: expose yourself to great work, but don't stop at liking it. Try to understand what makes it good. In software, that means studying the products you use rather than simply consuming them. 1
That's the important distinction.
Don't just use good software. Study it.
Good design usually looks easier than it was
One of the things I keep coming back to is how often good design looks obvious in retrospect.
Not because it was easy.
Because somebody did the hard work of removing everything that wasn't necessary.
Notion is a good example.
Its interface is remarkably quiet. There's a lot of restraint in the typography, color, spacing, and interaction model. It doesn't constantly try to impress you.
That simplicity is deceptive.
A simple interface isn't necessarily a simple product.
Often, it's the result of hundreds of decisions about what not to expose.
That's one of the things I find interesting about taste in software:
The better the judgment, the less evidence of the judgment you sometimes see.
The final product just feels obvious.
Paul Graham makes a similar observation about good design: the finished result can look effortless even when getting there required a great deal of practice, iteration, and precision. 2
Taste is subjective. That doesn't make it arbitrary.
Of course taste is subjective.
We all bring different experiences, cultures, references, and preferences to what we make.
But I don't think “taste is subjective” should end the conversation.
It should start it.
If I dislike an interface, I should be able to ask myself whether I dislike it because it genuinely solves the problem poorly or because it simply isn't what I'm used to.
And if I like something, I should be able to explain why.
Is it the hierarchy?
The restraint?
The interaction?
The typography?
The way it responds to an error?
The fact that I never have to think about where to click?
Taste becomes much more useful once you can separate preference from judgment.
There are patterns that survive changes in fashion.
Clarity.
Hierarchy.
Proportion.
Consistency.
Good feedback.
Solving the right problem.
These things can wear different visual styles, but the underlying principles keep showing up.
Taste changes with culture and exposure, but that doesn't mean everything is equally good. Our preferences are personal; our ability to reason about those preferences can still improve. 3
Taste can be trained
The good news is that I don't think taste is fixed.
You can train it.
Use things made by people whose work you respect.
Look outside software too. Architecture, photography, industrial design, typography, film, furniture. Anything that makes you stop and think, why does this feel good?
Save things you like.
But don't stop at saving them.
Ask why.
Then build.
And occasionally build something you know isn't good.
That's useful too.
Because there's a frustrating stage in learning any craft where your taste becomes better faster than your ability.
You can suddenly see everything that's wrong with your work, but you can't yet make it as good as you want.
That's not failure.
That's the gap closing.
Your eye is getting ahead of your hands.
Eventually, the two start catching up.
Paul Graham describes this gap directly: as you improve at making things, your taste changes too. Being able to recognize that your own work isn't yet where you want it to be is part of the process. 2
Taste isn't a style
Having taste doesn't mean your products need to look minimal.
It doesn't mean everything should be black and white.
It doesn't mean using rounded corners, glass, gradients, or whatever happens to be popular this year.
Taste isn't a visual style.
It's the ability to make good decisions within a set of constraints.
And the more you build, the more those decisions become instinctive.
You start noticing the one-pixel misalignment.
The unnecessary state.
The animation that feels slightly too slow.
The component that's trying too hard.
The feature that solves the wrong problem.
You don't necessarily need to explain all of it anymore.
You just know something is off.
And then, ideally, you know how to fix it.
Building is getting easier. Judgment isn't.
This is probably why I think taste matters more for developers now.
We're entering a world where building software is becoming dramatically easier.
AI can generate components.
It can write APIs.
It can scaffold applications.
It can turn an idea into something usable in an afternoon.
That's incredible.
But it changes the question.
When everyone can build, what separates what gets built?
I don't think it's just technical ability anymore.
It's judgment.
What should you build?
What shouldn't you build?
Which interaction is worth polishing?
Where should you introduce friction?
Where should you remove it?
What deserves attention?
What can stay boring?
The ability to answer those questions is a form of leverage.
Emil Kowalski makes this point in the context of modern software: simply shipping something that works is becoming less of a differentiator as the baseline for functional software gets easier to reach. The experience around that software matters more. 1
Stripe's discussion of craft and beauty in software makes a related argument from another direction: form isn't decoration added after function. The way something is shaped can be part of how well it functions and how people experience it. 4
Taste isn't knowing what looks good. It's knowing why something feels right and having enough craft to make it that way.
And I think that's becoming an increasingly important skill for developers.
Not because developers need to become designers.
But because when the cost of building keeps falling, knowing what is worth building and making it feel right becomes the harder part.
References
Footnotes
-
Emil Kowalski, "Developing Taste." The essay connects taste in software with exposure to great work, studying why things feel good, and deliberate practice. It also argues that shipping functional software alone is becoming less of a differentiator. ↩ ↩2
-
Paul Graham, "Taste for Makers," February 2002. A foundational essay on taste as a practical skill for people who make things, including ideas around simplicity, solving the right problem, redesign, and the gap between taste and ability. ↩ ↩2
-
Raphael Salaja, "The Concept of Taste," March 11, 2025. Explores taste as something shaped by exposure, culture, critique, principles, and historical context rather than purely individual preference. ↩
-
Stripe Sessions, "Craft and beauty: The business value of form in function," 2024. Explores the relationship between craft, form, function, and the value of thoughtful design in software. ↩