reviewing pull requests: challenging what we'll regret later

reviewing pull requests isn’t about perfection. it’s about avoiding future headaches.

stop nitpicking spaces and semicolons. stop obsessing over 100% code coverage. that’s lazy thinking disguised as thoroughness. when i review, i ask: what will we regret not fixing now?

tests aren’t a safety net if they suck. writing tests to hit 100% coverage is duct tape on a leaky pipe. write tests that break when something important fails, not tests that make your coverage report pretty.

your CI is your best reviewer. it doesn’t get tired or miss edge cases. when you spot a bug, write a regression test:don’t blame humans.

lazy reviews are easy. good reviews hurt. anyone can stamp “LGTM.” real reviews say “add a test for this” and challenge assumptions. a good review might piss people off: but it saves future you from 3am debugging.

fix things, don’t workshop them to death. when bugs happen, write a regression test and fix it. endless post-mortems are procrastination dressed as productivity.

complexity is evil. kill it. if you had to stop and think, others will too. simplify or comment.

match reviewers to their superpowers. find the person who knows where the bodies are buried. sometimes that means waiting for the domain expert.

ask the big question: what will future us hate about this?

it’s not about whether it works now: it’s about whether it’ll work next year when someone else touches it.

stop reviewing. start preventing.

related: simple over complex on killing complexity before it kills you. write good code on making code others actually want to use.