Review Your Own Pull Request Before Anyone Else Does

By the time you open a pull request, you have read your own code a dozen times - as its author. That is exactly the problem. You see what you meant, not what you wrote. A self-review pass, done in the diff view rather than your editor, catches the gap between the two while it is still free to fix.

Read the diff, not the code#

Your editor shows the final state with all the context in your head. The diff shows only what changed, which is what your reviewer gets. Open the “files changed” view - or run it locally:

git diff main...HEAD

Read it top to bottom as if a colleague sent it. The first things that jump out are usually embarrassing in a useful way: a leftover dump() in a Laravel controller, a commented-out block, a migration that adds a column the model no longer uses.

The usual suspects#

A short checklist beats good intentions:

• Debug leftovers: dump(), dd(), console.log, stray log channels.
• Dead code: commented blocks, unused imports, variables set and never read.
• Names that made sense mid-thought: $data2, $temp, $result where the domain has a real word.
• Tests that prove the happy path only - the code review habits post has the reviewer-side version of this list.
• Anything you cannot explain in one sentence. If you struggle, the reviewer will too.

Annotate the non-obvious parts#

Some lines are strange on purpose: a workaround for a queue driver quirk, an index added for one specific report. Leave a comment on your own PR explaining them before anyone asks. It saves a review round, and it pairs naturally with a good pull request description - the description says what and why, the inline comments say “yes, this odd line is deliberate.”

Self-review also keeps the whole pipeline honest: PRs stay small and reviewable, commits stay tidy, and your reviewer’s attention goes to the decisions that actually need a second brain instead of the typos that needed a second pair of eyes - yours, an hour later.