How do you give code review feedback that actually changes how someone writes code?

I treat review as teaching first and a net second, because the net is mostly automated anyway. So I sort every comment into three kinds and label them: blocking, question, and nit. If it is a nit and there are more than two of them, I delete them and leave one comment saying the file needs a formatter rule, not a reviewer. For a blocking comment I try to write it the way I would say it aloud, with the cost attached. On a component pack we were building for a grocery client, instead of "don't do fetch in the component", I wrote that the fetch here runs on every re-render, and that on the store locator page that had already been our second-largest source of client errors, so could we hang it off the loader we use elsewhere. That comment gets acted on; the first version gets argued with. My other rule is that the third time I write the same comment to the same person, I stop writing it. I did that with a contractor on the same build — we paired for forty minutes on the data-loading pattern, and I put an example in the pack's README, which was the real gap. Errors on the storefront went from 2.9% of pageviews to 0.8% that quarter, and I stopped writing that comment entirely.

At the agency I was responsible for frontend quality across six client pods, seventeen engineers, and the review problem was variance: two pods blocked on formatting, one approved anything that compiled. Neither was teaching anybody. I did three things. First, I wrote down what review is allowed to block on — correctness, data handling, anything another pod has to consume — and said explicitly that style is the formatter's job. That removed most of the arguments. Second, I asked reviewers to attach a cost to every blocking comment; if you cannot say what breaks, it is a question, not a block. Third, we put the good comments in the open: once a fortnight I posted one well-written review comment in the shared channel with the author's name on it, and I never posted a bad one, because correction goes in a private message. The hardest part was coaching two leads whose reviews were technically excellent and quietly discouraging. I sat with each of them, read three of their own threads back, and asked what they thought the author felt. One changed immediately; the other needed a second conversation and a month. Across the eleven live client sites, sessions hitting a client-side error dropped from 3.4% to 1.2% over two quarters, and the share of pull requests needing a second review round fell from just over a third to about one in nine.