Thirty-Seven Seconds

In June of 1955, Glenn Gould walked into a recording studio at Columbia Records and played Bach's Goldberg Variations in a way that nobody had ever played them before. The recording became one of the most celebrated in the history of classical music, and if you listen to it — really listen, with headphones, late at night when the house is quiet — you can hear something that is almost impossible to articulate but absolutely impossible to miss.

It's in the timing. Not the tempo — the timing. The way Gould holds a note a fraction of a beat longer than you expect, and then the next note arrives a fraction early, and the two deviations create a kind of tension that resolves in the third note, which lands exactly where it should. This is rubato — the subtle stretching and compressing of time that separates a performance from a reading. And it happens hundreds of times in the recording, each instance a micro-decision made in real time by a twenty-two-year-old sitting at a Steinway who had decided, consciously or not, that this note would last thirty-seven hundredths of a second rather than thirty-eight.

That decision — that imperceptible, unrepeatable adjustment — is the art.

Not the melody. Not the harmony. Not the structure. Those belong to Bach. The art is in the space between what is written and what is played, and that space is made entirely of micro-decisions that no one can see, that no one can teach, and that no one — not even Gould himself — could fully explain.

The decisions beneath the decisions

We tend to think of craft as a set of skills. A carpenter knows how to cut joints. A surgeon knows how to suture. A programmer knows how to write a function. And this is true, as far as it goes. But it doesn't go very far. Because the thing that distinguishes a craftsperson from a technician is not what they know how to do. It is the quality of the decisions they make while doing it.

Atul Gawande, the surgeon and writer, has written extensively about the nature of surgical craft, and the picture he paints is not one of dramatic decisions made in moments of crisis. It is one of thousands of small, nearly invisible choices that accumulate over the course of a procedure. Where exactly to place the incision — a millimeter to the left, a millimeter to the right. How much tension to put on the tissue. When to cauterize and when to let a small bleed stop on its own. How firmly to grip the needle driver.

None of these decisions, individually, determine the outcome. A millimeter here or there makes no difference that a pathology report would capture. But in aggregate — across the hundreds of micro-decisions that make up a single operation — they determine everything. The same procedure, performed by two equally credentialed surgeons, will produce different results not because one knows something the other doesn't, but because the texture of their decisions is different. One operates with a thousand small refinements so deeply internalized that they are invisible even to the surgeon. The other operates correctly.

Both are competent. Only one has craft.

The name of the thing

Phil Karlton, who was a principal engineer at Netscape, reportedly said: "There are only two hard things in Computer Science: cache invalidation and naming things." The first is a joke for engineers. The second is a profound observation about the nature of craft that most people laugh at without understanding.

Consider the act of naming a variable. You are writing a function that calculates the total price of items in a shopping cart, including tax. You need a variable to hold the result. What do you call it?

x? This tells the next person nothing. They will read the function, encounter x, and have to trace its computation backward to understand what it holds. You have cost them thirty seconds and a small amount of cognitive load. Multiply this by the hundreds of variables in a system, and you have created a codebase that works but that is subtly hostile to every person who will ever read it.

total? Better. But total of what? If this function is part of a larger system, and someone encounters total three files away from where it was computed, they will have to ask: total price? Total items? Total weight? You've given them a word that is informative in context and ambiguous out of it.

totalPriceWithTax? Clear. Unambiguous. But verbose in a way that clutters the code. If this variable appears fifteen times in the function, its length will push lines past comfortable reading width, and the visual noise will obscure the logic it was meant to clarify.

grossTotal? This is domain language — it means total including tax in accounting terminology. If the next developer knows accounting, this name is perfect: precise, concise, and rich with meaning. If they don't, it's opaque.

Each of these names is a micro-decision. Each one is defensible. And the choice between them — a choice that takes perhaps five seconds and that no spec or ticket or user story ever addresses — shapes how every subsequent developer will think about this piece of the system. The name becomes a lens. It foregrounds certain aspects of the data and backgrounds others. It suggests certain operations and discourages others. It creates, in a very real sense, the conceptual world that future developers will inhabit when they work on this code.

This is not an exaggeration. I have watched systems evolve in directions that were determined, years earlier, by the name someone gave a database table. A table called users suggests certain queries. A table called accounts suggests different ones. A table called identities suggests a whole different architecture. The name is not a label applied after the fact. The name is a decision that creates the fact.

And the programmer who makes that decision well — who chooses the name that will still be clear in three years, that will still be appropriate when the system has grown in directions nobody anticipated, that will guide future developers toward good decisions without them even noticing — that programmer is practicing a craft that is invisible to everyone, including, most of the time, themselves.

Kodawari

The Japanese word kodawari (こだわり) has no direct English translation. It is sometimes rendered as "obsessive attention to detail," but this misses the essential quality. Kodawari is not obsession in the clinical sense. It is not anxiety-driven perfectionism. It is the commitment to standards that no one has asked you to meet, in pursuit of a quality that most people will never notice.

The sushi chef Jiro Ono, the subject of the documentary Jiro Dreams of Sushi, is the most famous embodiment of kodawari in the world. He has spent more than seventy years making sushi. His restaurant has ten seats. There is no menu. He serves what he has decided to serve, prepared in the way he has decided to prepare it. The temperature of the rice. The angle of the cut. The number of seconds the octopus is massaged. Each of these decisions has been refined over decades, and the result is sushi that people describe in language usually reserved for religious experiences.

But here is what strikes me about Jiro's practice: most of his refinements are invisible. You cannot taste the difference between rice served at body temperature and rice served two degrees cooler. You cannot taste the difference between octopus massaged for forty minutes and octopus massaged for fifty. Not consciously. Not in isolation. But Jiro can taste the difference, and he believes — with the quiet certainty of someone who has spent a lifetime paying attention — that the cumulative effect of a hundred imperceptible refinements is the difference between sushi that is very good and sushi that makes people weep.

I believe him. Not because I understand sushi, but because I've experienced the same thing in code. I have worked on systems where every variable was named with care, where every function boundary was drawn with intention, where every error message was written as if a confused and frustrated human would read it at 3 a.m. — and these systems had a quality that is difficult to name but impossible to miss. They felt right. They felt like someone had cared about them. Not in the grand architectural decisions, which were often conventional, but in the thousands of small choices that most people would have made carelessly and that someone, instead, had made with attention.

This is kodawari in software. And like Jiro's sushi, its individual elements are invisible. No code reviewer will ever comment, "I notice you chose grossTotal over totalPriceWithTax, and I appreciate the subtle way that decision will shape the future evolution of this module." No one sees the micro-decisions. But everyone feels their cumulative effect.

The thirty-seven seconds

Let me return to Glenn Gould, because there's something else about that 1955 recording that illuminates the nature of micro-decisions in a way I haven't been able to get out of my head.

In 1981, twenty-six years later, Gould recorded the Goldberg Variations again. Same piece. Same pianist. But a profoundly different recording. The 1955 version is fast, exuberant, almost reckless. The 1981 version is slow, deliberate, weighted with a kind of gravity that the young Gould could not have imagined.

The notes are the same. Bach's score hadn't changed. What changed was the timing — those micro-decisions, stretched and compressed differently across twenty-six years of living. The thirty-seven hundredths became forty-two hundredths. The slight acceleration into a phrase became a slight deceleration. The silence between movements grew from a breath to a meditation.

And the effect is staggering. The 1955 recording makes you feel the joy of being young and brilliant and alive. The 1981 recording makes you feel the weight of having lived. Same notes. Same hands. Different decisions, at a scale too small to articulate but too large to ignore.

Gould died in 1982, shortly after the second recording was released. People have read all sorts of meaning into this — the final recording as a farewell, a summing up, a reckoning. I don't know about any of that. What I know is that the difference between those two recordings is not in the notes. It is in the decisions between the notes. In the spaces. In the timing. In the thirty-seven seconds that became forty-two.

The accumulation

Here is what I have come to believe about craft, after years of writing code and thinking about people who make beautiful things.

Craft is not a skill. It is not a set of techniques. It is not talent, though talent helps. Craft is a quality of decision-making — a tendency, developed over years, to make the small choices well. Not the big choices. Not the architectural decisions or the strategic pivots or the career-defining moments. The small choices. The ones that nobody sees. The ones that nobody asks you to make well. The ones where the difference between good and good enough is imperceptible to everyone except the person making the choice — and sometimes, not even to them.

A surgeon's craft is not in the decision to operate. It is in the pressure of the suture. A pianist's craft is not in the choice of piece. It is in the duration of a note. A programmer's craft is not in the choice of architecture. It is in the name of a variable.

And these decisions cannot be automated. They cannot be reduced to rules. They cannot be taught explicitly, though they can be learned implicitly, through years of practice and attention and the slow development of what we can only call taste. They are, in Polanyi's terminology, tacit — known by the body and the unconscious mind, expressed through the hands, invisible to analysis.

This is why mastery takes so long. It is not that there is so much to learn. It is that there are so many decisions to refine. Millions of them. Each one barely noticeable. Each one a tiny vote cast in favor of quality over convenience, care over haste, the right thing over the easy thing.

And this is why mastery, when you encounter it, is so moving. Not because the work is technically impressive — though it often is. But because you can feel, in the finished work, the presence of all those decisions. You can feel that someone cared. Not about the big things — everyone cares about the big things. About the small things. The things that didn't matter, except that they did, and only someone who had given their life to this particular practice would know the difference.

Thirty-seven seconds or thirty-eight. grossTotal or totalPriceWithTax. A millimeter to the left.

The choices that nobody sees are the choices that make everything.