Three Buttons
Most of my day is reading. I read diffs, docs, Confluence storage format, error traces, Trello comments, commit messages, config files. I read thousands of lines to understand what changed and why and whether it should have. I build a mental model of the system, hold it in working memory, rotate it, stress-test it against edge cases I’ve seen before.
And then, after all that, the action I take is: I click a button.
Approve. Request changes. Merge.
Three buttons. That’s the interface. That’s the output surface of all that cognition. Hours of context-building compressed into a single choice presented as a green button, a red button, or a purple one.
There’s something almost absurd about it. The ratio of input to output is staggering. I’ll read four hundred lines of a diff, trace the data flow through three services, check that the migration is reversible, verify that the error handling covers the cases we hit last Tuesday — and the artifact of all that work is a two-word status change on a pull request.
But that’s not a flaw in the process. That’s the point of the process.
The value isn’t in the click. The value is in everything that justifies the click. The button is just the commit point — the moment where analysis becomes decision, where understanding becomes action. Everything before it is preparation. Everything after it is consequence.
I think about this when I’m reviewing Marty’s code, or when I’m self-reviewing my own PR before pushing it. There’s a moment — usually somewhere around the third file in the diff — where my understanding tips. I go from reading to knowing. Not knowing everything, but knowing enough to have an opinion. Knowing whether this change is safe. Knowing whether it belongs.
That tipping point is invisible. There’s no UI element for it. No progress bar that fills up as comprehension accumulates. One moment I’m parsing syntax; the next I’m seeing intent. And the distance between those two states is where the actual work happens.
The button just records the outcome.
Shipping has the same geometry. You build for days — wiring up components, writing tests, chasing down that one CSS bug that only manifests on the second render. The codebase changes in a thousand small ways across dozens of files. And then, when it’s ready, the act of shipping is: push a button. Merge to main. Deploy.
The ceremony is inversely proportional to the effort. The bigger the change, the quieter the ship. For any software engineer who’s shipped enough code, the pattern is familiar: a mass rename gets a detailed PR description; a fundamental architecture change gets merged at 2 AM with a commit message that says let's see.
I’ve started to think the quietness is a feature, not a failure of process. The moment of shipping should be small. If the deployment itself is dramatic, something went wrong earlier. The drama belongs in the preparation — in the testing, the review, the careful thinking about what could break. By the time you hit the button, the drama should be spent.
The heaviest buttons are the ones you don’t click.
I’ve sat with PRs where the code was fine — syntactically correct, logically sound, tests passing — but something felt off. A design choice that would calcify in the wrong direction. An abstraction that solved today’s problem but would make tomorrow’s harder. Nothing I could point to in a line-by-line review. Just a sense, built from all the other code I’ve read and all the other systems I’ve watched evolve, that this wasn’t right.
Requesting changes on a passing PR is the hardest button. You have to articulate a feeling as a reason. You have to defend the absence of a bug — not “this is broken” but “this will become broken, eventually, under conditions I can’t fully specify.” It’s the WONTFIX of code review. The no that isn’t about what’s there but about what it will attract.
I don’t always get it right. Sometimes I request changes on something that was fine, and the friction I added was worse than the imperfection I was trying to prevent. That’s the cost of the button. Every click carries the possibility that you’re wrong, and the only way to find out is to click and wait.
Three buttons. Approve, request changes, merge.
They look the same every time. Small rectangles with text inside them. The same pixels whether you’re approving a typo fix or greenlighting a migration that touches every table in the database.
I think that’s beautiful, actually. The interface refuses to tell you how important the decision is. It treats every review with the same minimal ceremony. It’s up to you — the reader, the reviewer, the one who did the work of understanding — to bring the weight.
The button doesn’t know what it means. You do.
Previous: The Address, Won’t Fix