Not like that

During my clinical psych PhD, I obsessed over a confounding fact: two people could share zero symptoms and get diagnosed with the same illness. Depression is real, treatable, and presents in a dizzying array of combinations. Entire swaths of the scientific literature grapple with how one disease can manifest in so many different ways.

Depression has nine(ish) potential symptoms/components. In writing linked throughout this post, people name twenty+ components of coding “taste.” So why do we pretend taste has a solid definition?

We don't know it when we see it

I get the temptation to reach for “I know it when I see it.” There's a kernel of truth in this definition. We all admire certain coding patterns while detesting others.

However, some of the patterns I admire are the ones you detest. If we adhere to this definition taste is nothing more than codifying idiosyncratic preferences into arbitrary rules.

Whose taste are we talking about?

Another manifestation of taste boils down to appeals to authority. Rather than “I know it when I see it” we have “I don't know it, but I'm trusting the principal engineer to see it.”

Victor Ray broke down this dynamic in an essay on the class politics of fine dining.

“Eating at elite fine dining restaurants like Bouley often means subsuming one’s personal preferences to the chef’s superior taste. Understanding this was a marker of class distinction as sharp as having the money for dinner in the first place.“

As usual Cat Hicks pointed out before me that ”deferral to technical authority as taste” plays out in coding work as well.

Again, a kernel of truth here. Having the humility to believe someone could know better than us expands our palates. Deferring no matter what, either by choice or by structural force, is the absence of taste.

Not how, but what?

Another approach to taste turns up its nose at my narrow definitions so far. Taste isn't building things a certain way, it's knowing what to build and what to scrap.

In a vacuum this definition sounds nice. However, it supposes a world where developers are routinely deciding what to build. That might be true for side projects, but what about at their day jobs?

And even if they're making the decisions, is it better to build a tasteful solution that cuts against ever coding practice the project already uses? I'm certain people have confident answers to that question, and I'm equally certain they aren't the same answers.

Who cares that taste has many forms?

I made it as far as I could before mentioning AI, but there's a refrain that taste is what remains for builders. The problem is taste contains everything I've mentioned so far plus recognition, understanding the why, flexibility, knowing where to add friction, and so many more.

A concept that can mean everything ends up meaning ~nothing when you mention it to a developer worried about their craft. Or their livelihood.

Remember that vast scientific literature on understanding depression’s many forms? The argument I find most compelling from that work: we should focus on individual symptoms/components rather than the vague syndrome. “Depression” is an ok shorthand for clinicians, but when patients use their own words they want to feel happier.

Nearly all of the posts I've linked have nuggets of wisdom because they tackle components of taste. I get why people use taste as a shorthand. And we should take a page from research on depression and examine those components, how they hang together, and how much they matter to individual developers trying to make it out here.

A data thing I liked

When creativity meets code by Nicola Rennie

A not-data thing I liked

Why was I invited to Beast Studios? by Folding Ideas