When someone reviews my work and tells me it answers the request but is not strong enough yet, there is a flinch. It lasts a second or two, and it usually sounds like one question: do they know what I was working with? If I was quietly unsure about that piece of work and somebody names it out loud, my first reaction is not curiosity. It is being caught.
It passes quickly. What matters is the second reaction, because that is the one that decides whether the conversation is useful, and it is always the same question: is this specific? Sitting on both sides of that moment for many years has taught me that most of what makes a review useful is settled before anyone says a word, in how the reviewer sorted what they were about to say.
- Why "it technically answers the request" is the wrong place to set the bar, and the three questions I ask instead.
- The test for whether one more round of polish is worth anyone's time.
- The habit that makes a review easy to act on for the person receiving it.
Where the Bar Actually Sits
"Technically answers the request" is not the bar I use. It is the bar that gets work through a review and into trouble later. The bar I use is whether the work does the job for whoever picks it up next: the customer, the engineer on call, the person who has to change it a year from now.
So I start with three questions.
If any of those is a no, the work is not done, and no amount of polish elsewhere changes that. The third question is where the customer's interests live: when something fails, somebody absorbs it, and that somebody should never be them. The most human version of that idea I know comes from a ship, and from the men who kept the lights on in her engine room.
Is Another Round Worth It?
If all three are yes, the remaining question is whether another round is worth it, and that turns on how expensive the work will be to change later.
If it is easy to change, I ship it and improve it on real evidence. If it hardens, and some things harden quickly (an API contract, a data model, a name that will propagate through a codebase, a security boundary), then another round now is cheap and the same fix later is not. It is the same test I apply to decisions, the difference between a door you can walk back through and one you cannot, pointed at a pull request instead of a strategy.
Then I ask the question that is hardest to answer honestly: does another round change something for the person using it, or does it only satisfy me? Some polish is real and some is taste, and I have spent effort on the wrong one before.
Make the Bar a Number
Where I can, I make the bar objective rather than an opinion: a service level objective, an error budget, a defect rate. The argument still happens when you do this. It just happens earlier, at the moment you agree the number, which is the same reason the criteria belong on the board before the options go up.
Good enough is a number we agreed on, not a question of who feels most strongly in the review.
Not every piece of work gets a number. Plenty of what lands in a review is a name, a structure, or a boundary between two modules, and no dashboard will settle those. Even then, asking whether a number could exist moves the conversation away from whoever holds the strongest opinion and towards what the work is for.
Say Which Is Which
And when I send work back, I separate what is blocking from what is preference, and I say which is which. If everything is a comment, nothing is.
A review that arrives as a flat list of equal comments hands the author a sorting problem. They either change everything, and pay for my taste, or they change what they happen to agree with, and the comment that mattered ships alongside the ones that did not.
The label is a promise in both directions. Blocking promises the author that this one matters. Preference promises that the work will not be held hostage to how I would have done it.
How to word an objection so the room stays open is its own discipline, and I have gone at that half in a separate essay. This one is about the sorting that should happen before a single word is written.
On the Receiving End
Back to the flinch. It passes, and then comes the reaction I actually trust: is this specific? "Not strong enough yet" on its own gives me nothing to act on, and I will push back, not on the judgement but on the vagueness. Tell me what is weak and for whom, and I can do something with it.
If it comes with specifics, I am happy to revisit my choices. Someone spending their own time to tell me my work is not there yet is doing me a favour. The expensive version is the colleague who thinks it and says nothing, which is why silence when somebody knew sits on the list of things a team should refuse.
Seen from that chair, the sorting is what turns a review into something the other person can use the same afternoon.