reviewing pull requests

• reviewing pull requests isn’t about perfection
• it’s about avoiding future headaches
• stop nitpicking over spaces and semicolons
• stop obsessing over 100% code coverage like it’s a holy grail
• that’s lazy thinking disguised as thoroughness
• when i review, i ask: what will we regret not fixing now?

tests that matter

• tests aren’t a safety net if they suck
• writing tests to hit 100% coverage is like using duct tape to fix a leaky pipe
• it looks fixed but still breaks when you need it most
• write tests that break when something important fails
• not tests that make your coverage report look pretty

ci is your best reviewer

• your CI is your best reviewer
• it doesn’t get tired or miss edge cases when properly fed
• when you spot a bug, write a regression test - don’t blame humans
• expecting people to catch what robots should is backwards thinking

good reviews hurt

• lazy reviews are easy - good reviews hurt
• anyone can skim and stamp “LGTM”
• anyone can nitpick variable names
• real reviews say “add a test for this” and challenge assumptions
• a good review might piss people off
• but it’ll save future you from 3am debugging hell

fix don’t workshop

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

complexity is evil

• complexity is evil - kill it
• if you had to stop and think, others will too
• simplify or comment
• complexity piles up until it suffocates your project

match reviewers to superpowers

• match reviewers to their superpowers
• don’t assign reviews democratically
• find the person who knows where the bodies are buried
• sometimes that means waiting for the domain expert

the big question

• 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.