Skip to content
Published on

When Friction Disappears, Taste Does Not Remain — the Path to Growing Taste Disappears

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

All Twelve PRs in the Review Queue Are Fine

Monday morning, twelve PRs in the review queue. Every one of them has tests attached, tidy names, conscientious comments. Look at them one by one and there is no reason to reject any of them.

But look at them all together and five of the twelve are features that should never have been built in the first place. There is one more option, three more config keys, and one more person who will have to maintain this going forward. When you try to write the rejection reason, the only sentence that comes out is "the code is fine but I do not see why we are building this," and that sentence looks rude as a review comment.

Friction Was a Filter, and a Filter Is Only Visible After It Is Gone

Taste Is All That Is Left, published on August 6, 2026, takes this situation head on. The core of the piece is the observation that effort was a filter. And, as with every filter, it was invisible until it was removed.

It used to take three days to build a feature. That three-day cost was itself a screening. It forced you to ask yourself whether the thing was worth three days, and half of the mediocre ideas died at that question. Now the same feature comes out in 40 minutes. Forty minutes is too cheap a price to pass a screening.

So things that should not have been built get built. And they are harder to argue against because they were not built badly.

The Shape of the Path That Made Taste

What the same piece points to as more important is the next passage: that taste is built slowly, stupidly, and embarrassingly. It is the process of making bad things, having to live with them, and failing in front of people.

Take this sequence apart and you can see why each stage is needed. In the stage of making a bad thing, the causal link "do it this way and this happens" gets written into your body. In the stage of living with it, maintenance cost turns into an instinct. In the stage of failing, the gap between your own judgment and reality gets measured.

All three take time and all three are unpleasant. And all three happen only when the artifact is bad.

What Is Happening to Juniors Right Now

Here is where the problem arises. As the original observes, people starting now do not get the chance to ship a bad version and sit inside it, because the tool gives them a competent version for free.

This is not a matter of ability. Quite the opposite. A junior today builds something that works far faster than a junior of three years ago. It is just that in the process, the event from which they would learn "what will this choice cost me in six months" never occurs. They gain fluency and skip the apprenticeship.

And this gap does not register in metrics. It shows up in neither throughput nor lead time nor PR count, and then about two years later it shows up as a team where nobody can decide the structure. In a meeting nobody argues strongly for one of two options, and in the end you build both, or you go with the option of whoever spoke most recently.

One thing to add: this is not a story about a generation. Someone ten years in experiences it identically. The moment you start accepting the competent output a tool gives you in an area you are not familiar with, your judgment in that area stops growing right there. The only difference is that the instincts you built in other areas make it harder to notice on your own.

Where the Conclusion That Taste Is Everything Turns Dangerous

The original's final claim is strong: almost nobody can tell you what is worth building, that was always the harder skill, and now it is all that is left.

As a diagnosis it is persuasive, but you have to be careful when you turn this sentence into a prescription. Reading it as "all you need now is taste" is a problem, because taste is a byproduct of the experience of making, not a substitute for it. The judgment of someone who has never built anything is not taste but preference, and the difference between the two shows up when they are wrong.

The more accurate formulation is this one. The value of taste went up at the same moment the supply route for taste got blocked. Because both happened together, this is not good news but a problem.

Making Judgment Observable

So the first thing an individual can do is get the judgment outside. Taste is by nature an ability that operates silently, and what operates silently can be neither verified nor transmitted.

Concretely, it goes like this. Before you build something, write two or three lines. What you are going to build, why now, and what happens if you do not build it. Then after you build it, read the note again. Once six months of these accumulate, you can see which direction your predictions err in. Most people err consistently toward overestimating "what happens if I do not build it."

This note does not have to be a design document. In fact, if it is long you will not write it. The body of a commit message or the first comment on an issue is fine; three lines somewhere you can find again is enough. What matters is not the length but the fact that it was recorded at the moment the judgment was made. A retrospective written after you know the outcome reconstructs your own judgment and is useless as learning material.

Three Habits That Deliberately Restore Friction

The second thing is to artificially revive the friction that disappeared. You do not have to revive all of it, only the points where learning used to happen.

HabitConcrete actionWhat it revives
Decide your own answer firstWrite the design in one paragraph before you call the toolMeasuring the gap between your judgment and the competent default
Force alternativesAfter the first result, build two more approaches and compareJudgment that only exists when there are several options
Live with what you builtOwn the operations and incident response of the feature you built for at least a quarterThe experience of maintenance cost turning into instinct

The third item has the biggest effect and is the most often skipped. If the person who builds and the person who maintains are separated, taste accumulates on neither side. The builder does not pay the price, and the maintainer does not know the context of the choices. When the org chart is drawn that way there is often nothing an individual can do, but in that case it is better to at least keep receiving the incident alerts for what you built.

The second item has a trap of its own. Ask a tool to produce three alternatives in one go and you will generally get three that resemble each other, because they circle the same default. So at least one has to be made by hand, and if possible under the opposite constraint, before the comparison holds. For example, try the constraint "solve it without adding a single configuration option."

What a Team Can Change Is the Question the Review Asks

The last part is organizational. Code review today is designed to ask "is this code correct," and tools already answer that question quite well. If reviews keep asking only that question, there will be nothing left to learn from a review.

Move the question one step earlier. Put a field for "alternatives considered and discarded, and why" in the PR template, and adopt a rule that review does not start while that field is empty. This one field does two things. It makes the author put the choice into words, and it gives the reviewer a place to look at judgment rather than at code.

Back to the twelve PRs at the top: five of them get caught in this field. Having no discarded alternatives usually means no alternatives were considered, and not considering alternatives means the option of not building it was never examined either.

References

Discuss on Twitter • View on GitHub