Notes from the Cutting Room, Vol. I
Short dispatches from the edit bay and the codebase — five small things we noticed this month, none of them large enough for an essay.
By Bill
Not everything worth saying deserves a thousand words. Some observations are just the right size as they are — noticed on the walk between the coffee machine and the desk, written down before they evaporate. Five of those, from a good month.
I. The best interface is the one you forget
We spent a week making a feature faster and the highest praise it earned in testing was that no one mentioned it at all. This is the strange economy of tools: attention is the cost, not the reward. A thing that works perfectly disappears, and a thing you keep noticing is a thing that is quietly failing.1
II. Latency is a feeling before it is a number
You can measure a lag in milliseconds, but the user experiences it as doubt. Under about a hundred milliseconds, an action feels like your own hand. Past it, however slightly, a sliver of the machine intrudes between intention and result, and the user starts — without knowing why — to trust the tool a little less. We treat the frame budget as an emotional budget, because that is what it is.
III. Directors and databases want the same thing
Both are trying to hold an enormous, shifting structure in their head and keep it coherent while it changes. The director does it with instinct and a shot list; the database does it with constraints and transactions. The more time we spend building for filmmaking, the less those two look like different problems and the more they look like one problem in two costumes.
IV. Delete more than you add
Our most satisfying pull request this month had a red number three times larger than its green one. The feature did not gain anything; it lost a special case that had been quietly costing everyone a half-second of confusion for a year. Subtraction is underrated in software for exactly the reason it is underrated in the edit: it does not photograph well, and it is almost always the right call.
V. Ship the version you would defend
There is always a faster cut and a cheaper build, and there is always a temptation to ship it and fix it later. The question we have learned to ask is simpler than any metric: would we stand behind this in a room full of the people who will use it? If the answer is no, later never comes, and the thing you shipped becomes the thing you are known for.
More next month, if enough small things add up again.
Footnotes
-
With apologies to every load-bearing tool that goes unthanked precisely because it never breaks — the unglamorous fate of good infrastructure everywhere. ↩