What Collin Morikawa's Golf Answer Teaches Developers About Quality

On Jim Nielsen's blog, a post about being "good" at things starts where you'd least expect a software essay to begin: a golf clip on social media. An interviewer asks professional golfers what score an amateur has to shoot to be considered good. The answers scatter across the 90s, the 80s, even the 70s. Then Collin Morikawa sidesteps the premise entirely. He doesn't think there's a number. He thinks you have to be able to finish out every hole without picking up a two-footer.

Nielsen, a frontend developer whose writing regularly circulates among design and web engineering circles, latches onto why that answer lands. The question itself is rigged. It frames a qualitative idea, what it means to be good, as if a single quantitative proxy could capture it. And anyone who has played golf knows how leaky that proxy is. An 82 on a casual round can mean wildly different things depending on whether you took mulligans, conceded short putts, or quietly improved a lie in the rough. The number survives. The honesty behind it does not.

The reframing matters because it transfers cleanly to the work most of us actually do. Substitute golf for programming, design, or writing and the logic holds. We love proxies. Test coverage percentages, Lighthouse scores, story points closed, lines of code, follower counts. Each is a standardized measurement that lets us compare across people and projects, and each is just as easy to game as a golf scorecard. You can hit a 95 on a performance audit while shipping an interface nobody can navigate. You can close every ticket in the sprint by quietly redefining what "done" means.

The hard part is finishing

Morikawa's real insight, in Nielsen's reading, is that finishing is the hard part. Not the heroic shot off the tee, but the discipline of holing out every two-footer under the actual rules of the game. The consistency of showing up to each hole and playing it honestly, without relieving yourself of the burden of reality.

This is the part of frontend work that doesn't photograph well. It's the focus state on the obscure interactive element. The keyboard trap nobody will hit until the one user who relies on a screen reader does. The loading state for the slow network you never test on because your dev machine is on fiber. The error boundary around the API call that almost never fails. The empty state. The reduced-motion media query. The form that still works when JavaScript hasn't loaded yet. None of these show up in a demo. All of them are the difference between an interface that looks good and one that is good.

The temptation to pick up the two-footer is constant in software because the tooling makes concession invisible. A skipped accessibility check leaves no scar in the codebase. A // TODO: handle error reads as progress. A component that works on the happy path passes its review. The work that separates good from passable is precisely the work that is easiest to skip without anyone noticing, until production notices for you.

Quality as a disposition, not a metric

What makes this framing useful rather than just inspirational is that it shifts the locus of quality from output to practice. A number is something you achieve once and report. A disposition is something you carry into every hole, every component, every pull request. Nielsen lands on this directly: good isn't a number, it's quality, a disposition, a way of being.

For anyone building interfaces, that reframing changes what you optimize for. Instead of chasing a green Lighthouse score, you build the habit of testing on a throttled connection. Instead of treating accessibility as an audit you pass before launch, you make tab order and focus management part of how you write every component from the first commit. Instead of declaring a feature done when it renders, you finish it when it handles the slow network, the failed request, the empty result, and the assistive technology.

The payoff compounds in a way scores never do. A developer who consistently finishes the small, unglamorous things builds a body of work that holds up under conditions the demo never covered. That reliability is what users actually experience, even when they can't name it. They don't see your test coverage. They feel whether the thing breaks when they do something slightly unexpected.

Nielsen's post is short and makes no claim to technical novelty, which is part of why it resonated. It names something practitioners across design and engineering recognize but rarely articulate: the gap between performing competence and practicing it. Doing the hard, little things that others gloss over, consistently and with discipline, is unglamorous and largely invisible. It is also, in golf and in software alike, the whole game.