A few years ago I submitted a PR that I was proud of. It was a clean refactor with tests covering the whole change. My senior dev reviewed it within the hour and left exactly one comment: "Is this var_dump intentional?"

It was not, but I had been debugging a gnarly data issue the night before, forgot to remove it, and shipped it straight into a code review.

It was right there in the diff. Thirty seconds of reading my own changes would have caught it. Instead, I made my reviewer spend time on something that had nothing to do with the change and wasted both of our time.

That was the moment I started self-reviewing every PR before I assigned it to anyone.

The Habit Is Simple, and That's the Point

Before you click "assign reviewers," open the "Files Changed" tab. Read through every change as if you're seeing it for the first time, written by someone else, and make sure everything that should be there is and that nothing "extra" snuck in.

The shift in perspective matters. Writing code fills your head with context about what you were trying to do and why, which makes it easy to skim past problems. Switching into reviewer mode strips some of that context, and you start seeing what's in the diff instead of what you meant to put there.

Even just two minutes of self-review almost always saves more time than it costs because your reviewers don't have to burn cycles on the obvious stuff and you don't have to interrupt their day for something that gets rejected immediately.

What You're Looking For

You're not doing a full formal review. You're hunting for the category of problem you'd feel terrible about if a teammate caught it first.

Anything you'd feel awkward explaining is the gut-check. If you're reading your own diff and thinking "I hope nobody asks about this," that's a signal. Clean it up or add a comment with the reasoning.

Debug calls sneak in during debugging sessions and are easy to miss when you're focused on the logic. console.log, var_dump, dd(), dump(), print_r, die(). A dd() in a Laravel controller almost certainly shouldn't ship (but it has...).

Stale comments are the ones that described what the code used to do before you refactored it, or that say "TODO: fix this later" when later was six months ago. Comments that contradict the current code make reviewers wonder which to trust.

Confusing variable names. $tmp, $data2, $result make sense when you're in the middle of writing. Reading back fresh, $data2 means nothing to anyone who wasn't in your head at that moment. If you have to re-read a line twice to figure out what a variable holds, rename it.

Logic that made sense at 2am. If your first reaction reading a block is "wait, why did I do it this way," your reviewer will have the same reaction. Take five minutes to either simplify it or leave a comment explaining the reasoning.

Why Your Reviewers Will Thank You

Code review is supposed to be about logic, design, and the edge cases a second set of eyes catches better than one. A PR full of debug statements and stale comments pulls reviewers into cleanup instead of that work.

Every time a reviewer catches something you could have caught yourself, it costs you credibility. It signals you didn't look at your own code before asking them to. Submitting PR after PR with var_dump calls or orphaned TODO comments tells your team you're not checking before handing off.

Do it consistently and your reviewers start trusting you. Feedback gets more substantive because nobody is stuck on the obvious stuff.

A Checklist Worth Keeping

Move through the diff looking for:

• Debug statements: console.log, var_dump, dd(), dump(), die(), print_r
• Comments that contradict the current code
• TODO/FIXME/HACK markers that are either resolved or orphaned
• Variable names that require context to understand
• Logic that felt clever but reads as confusing
• Anything you'd describe as "temporary" that doesn't have a ticket number attached

You don't need a formal checklist in a document somewhere. Run through those categories in your head as you scroll the diff. It takes less time than a standup.

The var_dump I shipped into that PR review wasn't the last mistake I've made in code. But it was the last time I made my reviewers catch something I could have caught myself with a few minutes of effort.