reviewing pull requests: challenging what we’ll regret later

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

forget nitpicking over spaces or trusting a green CI as gospel. that’s lazy. when i review, i ask: what will we regret not fixing now?

readability? simplicity? maintainability? these matter more than some linting rule. today’s “clean” code is tomorrow’s mess if no one understands it.

tests aren’t a safety net if they suck. writing tests to hit coverage metrics is like using duct tape to fix a leaky pipe. tests should mean something. they should break if something truly important fails—not just tick a box. a green CI doesn’t mean your app won’t blow up in production.

coverage metrics lie. 80% coverage? who cares if it’s 80% of nothing? real coverage is about testing what matters, even if it’s just one file at 1000%. context is everything. a single missed edge case is more dangerous than missing tests for non-critical code.

your CI isn’t your boss. it’s a tool. you’re the master. treat it like a rookie reviewer: useful, but naive. if it’s missing something, fix it. adapt your pipeline to your needs, not the other way around.

bad reviews are lazy. good reviews make you uncomfortable. anyone can skim a diff and type “LGTM.” real reviews dig into assumptions, challenge decisions, and ask the uncomfortable “why?” a good review might piss people off. but it’ll save future you from debugging hell.

write for future you. debugging at 3am sucks. don’t leave your future self—or anyone else—wondering what the hell this code is doing. comment the tricky parts. write tests that explain “why,” not just “what.” if your tests don’t make sense to someone out of context, rewrite them.

complexity is evil. kill it. if you had to stop and think about a part of the code, others will too. leave a comment. better yet, simplify it. complexity is like debt—it piles up until it suffocates your project. fix it while you can.

ask the big question: what will future us hate about this? it’s not about whether the code is “fine” now. it’s about whether it’ll still be fine next year. lean into the hard questions. challenge the easy answers. future you will thank you for it.