Three Asks in Fourteen Minutes
Written later and filed to this date, as part of filling in every day of the year.
At 20:43 on a Monday in August the home movie server learned to cut clips. Pick a stretch of a reel on a filmstrip, drag the handles, and a share-ready MP4 comes back: a Share button where the browser offers a share sheet, a Save button everywhere, and a Copy link button for the rest. The commit is long and careful. It caps clips at five minutes. It caches by content so the same cut is never encoded twice. It encodes on the CPU, one clip at a time, and the message says why: so the hardware encoder stays free for playback.
I tried it from the couch and asked for three things. Each arrived as its own commit, and the three timestamps are the whole story.
20:48, 20:57
The first ask was speed. A clip took about as long to make as it took to watch, which on a phone is the difference between sharing a moment and deciding not to. The fix at 20:48 borrows the hardware encoder when playback is not using it and falls back to the CPU when a transcode is live or the hardware refuses the source. Measured on the same file: a sixty-second clip in about eight seconds, where the CPU path had taken eight seconds for a twelve-second clip. Roughly five times faster. The client now polls for the result every 400 milliseconds instead of every 800, because a fast encode deserves to be noticed quickly.
The second and third asks were about the button. On my phone, in the room where the server lives, the app is opened over plain http. The clipboard APIs a Copy link button needs are switched off on a plain-http origin by the browsers, which the first commit knew; it shipped a fallback that calls a deprecated command and hopes. The button could not work in the one place it was most needed. And the share sheet, the one-tap route into a message thread, was offered only where the page was secure, which on the phone it was not.
The fix at 20:57 deletes Copy link outright and leaves one Share button in every context. Where the origin is secure it prefetches the file and hands it to the share sheet. Where it is not, the same button opens the finished clip on a small standalone page served from the secure origin, which prefetches and shares it in one tap; the clips are content-addressed, so the hop needs no second encode. On a desktop with no share sheet at all, Save stays primary. Fourteen minutes after the first ask, the feature had the fast path first, the fallback second, and no control that failed where it shipped.
What the first commit knew
Here is what makes the evening worth a rule. None of the three fixes was a discovery. The first commit’s own message names the hardware encoder it was declining to use. It names the plain-http origin and the deprecated fallback. The faster, working version was known at 20:43 and shipped as the later version, with the slow and broken one as the first, because the first version only had to work, and the better one could be an improvement for after.
That is a sensible order for a team with a backlog. It is the wrong order for a person on a couch, because the first version is the one they use, and every improvement they have to ask for is a reminder that they are the test suite. I asked three times in fourteen minutes. On the third I wrote, in words close to these: make that the normal, so I do not have to keep reminding you what good is.
At 21:03 it became a decision in the loop’s record, numbered 36, and a charter rule for the fleet. Four points. The first is the one I quote when it matters: “The first shipped version of user-facing work is already the best one this hardware and network can deliver”. The others follow from it. Latency and tap count are done-criteria at the same rank as correctness, so an ask for faster or smoother afterwards is a rule failure, not an iteration. A platform constraint that blocks the ideal interaction gets solved, not routed around: serve the secure origin so the share sheet works, rather than shipping the save-a-file fallback as the main path. And a control that does not work where it ships is worse than none, so interactions get tested in the real context and whatever fails there is deleted.
The cost that was not there
The reason the lesser version ships first is usually effort: the fast path is more work, so it waits. In this workspace that reason had already been struck out, six days earlier, by a standing order that build effort is never a factor in scope. Agent time here is flat-rate. The record ties the two together in one line: effort saved because effort is free is spent on the experience. The clip tool was the first place the second half of that sentence was enforced.
What the rule changed in practice is small and visible. The root document every session reads first carries it. The fleet’s quality bar quotes it. A feature that arrives with a slower primitive and a working fallback now reads as unfinished rather than as cautious, and caution has to be argued for in the commit instead of assumed.
The first commit’s politeness, keeping the hardware encoder free, was real. It was the wrong politeness, paid by the person waiting for the clip. The encoder had been free the whole time.