Reviewing your own PR first: what developers should know

The habit that separates good developers from great ones

You've pushed your branch, opened the pull request, and now you're waiting for your teammates to review it. But here's the thing: if you haven't thoroughly reviewed your own PR first, you're likely wasting their time and yours. Reviewing your own PR first—before a single reviewer touches it—is one of the highest-leverage habits you can build into your development workflow.

The reason is simple. When you review your own code immediately after writing it, you're still in context. You remember why you made certain decisions, you know which parts felt hacky, and you can catch obvious mistakes before they become someone else's problem. In this article, we'll walk through what developers should know about self-reviewing pull requests effectively, from reading the full diff to ensuring your tests actually pass.

Read the full diff on GitHub

The first step is to actually look at what you've changed. This sounds obvious, but many developers open a PR and assume it looks fine because their local branch works. That's not how code review works.

When you open your PR on GitHub, click into the "Files changed" tab and read through every single line you've modified. This is not a skim. Read it like a reviewer would—someone who doesn't have your mental context and is seeing the code for the first time.

As you go through, ask yourself:

• Are there any obvious logic errors or typos?
• Did I accidentally commit commented-out code or half-finished thoughts?
• Are variable names clear and consistent with the codebase style?
• Did I introduce any unrelated changes that should be in a separate PR?
• Are there any lines that make you think "wait, why did I do that"? If so, that's a sign a comment is needed.

Here's a concrete example. You've refactored a payment processing function. When you read the diff, you notice you changed the error handling in three different places, but only one of them logs to the monitoring system. That's exactly the kind of inconsistency that's easy to miss in your editor but obvious when you see the diff side-by-side on GitHub.

Use GitHub's comment feature on your own PR as you spot things. Leave yourself notes about what needs fixing or why a particular change is there. This becomes part of the PR's story and helps reviewers understand your reasoning.

Remove debug code before submitting

Debug code should never make it to code review. That means console.log statements, commented-out code blocks, temporary test data, or any scaffolding you created while developing.

When you're deep in development, these helpers are useful. But they clutter the review and create noise that makes it harder for your teammates to focus on the actual logic. More importantly, they signal that the code wasn't carefully prepared before submission, which affects how reviewers perceive the whole PR.

Here's what to look for:

• Console statements: console.log, console.error, or framework-specific debug output
• Commented code: If you're not sure whether to keep something, delete it. Version control lets you recover it if needed.
• TODOs and FIXMEs: These are sometimes legitimate, but ask yourself if they belong in this PR or in a separate issue
• Test data or fixtures: Make sure you're not checking in hardcoded test values meant only for local development
• Temporary imports or unused variables: Your linter should catch most of these, but double-check

Consider a real scenario: you're working on a feature flag system. During development, you added console.log(userFeatureFlags) to debug flag resolution. When you review the diff, that console.log jumps out as noise. Remove it. The code is cleaner, and reviewers know you've actually thought about what's ship-ready.

Add comments where context helps

There's a balance between self-explanatory code and code that needs explanation. When you review your own PR, you're the perfect person to identify which parts need a comment because you're about to lose context.

The best comments explain why, not what. Anyone can read code and see what it does. Comments should explain why you made a particular choice, especially if it's non-obvious or if there's a constraint others might not know about.

Common places that need comments:

• Business logic constraints: "We retry only 3 times because downstream API has rate limits"
• Performance decisions: "We cache this for 5 minutes because the data changes infrequently but queries are expensive"
• Workarounds: "We use parseInt here instead of Number because of a quirk in Safari's parsing"
• Complex algorithms: A few lines explaining the approach before dense code
• Gotchas in the codebase: "Order matters here—don't reorder these calls"

Here's a practical example. You're modifying a user provisioning function and you've added a 2-second delay before returning a response. Why? Because the downstream database has eventual consistency, and if you return immediately, the user's data won't be visible yet. That's worth explaining:

// Wait briefly for downstream DB to become consistent
// before returning. Users expect their data to be immediately visible.
await new Promise(resolve => setTimeout(resolve, 2000));
return { success: true, userId: newUser.id };

Without that comment, a reviewer might flag it as unnecessary latency. With the comment, they understand the constraint.

Check tests and screenshots

Before you consider your PR ready, verify that tests actually pass and that you've included evidence of your work—whether that's test output, screenshots of UI changes, or logs showing the feature working.

For tests, make sure:

• All existing tests pass (you didn't break anything)
• Your new tests exist and pass
• Test coverage for the new code is reasonable
• Test names clearly describe what's being tested

Run the test suite locally before pushing, not after. If you catch a failing test in CI later, you've already wasted the CI runner's time. Even better, run tests as you work, not just at the end.

For visual or behavioral changes, screenshots and videos matter. If you've changed a user-facing component, include a screenshot or screen recording in the PR description. If it's a backend change that has observable behavior, describe what changed or add log output.

Here's why this matters: a reviewer looking at your PR might think "this looks reasonable" but not realize the UI actually looks broken without seeing a screenshot. Or they might miss that you've added proper error handling for edge cases if you don't show them the error state in action.

In your PR description, you might write something like:

Added retry logic with exponential backoff for failed webhook deliveries. Tests cover success case, immediate failure, timeout, and max retries exhausted. Verified locally that failed webhooks are retried up to 5 times with 1s, 2s, 4s, 8s, 16s delays. See attached test output.

This tells reviewers exactly what's been tested and how to verify it.

Common mistakes

Assuming your local build works means your PR is clean: A working build doesn't mean your code follows the team's style, doesn't have temporary debugging lines, or isn't creating technical debt. Self-review is separate from testing.

Treating self-review as optional: Some developers think "the reviewers will catch issues." That's true, but it's not scalable. If every PR needs 2-3 rounds of fixes for things you could have caught, you're creating friction for everyone.

Being defensive about feedback: When you review your own code first, you're more likely to spot issues before others do. This makes you less defensive when they mention something—you're already thinking critically about the code. Developers who skip self-review often come across as resistant to feedback because they're seeing it for the first time.

Confusing self-review with code quality: Self-review is a discipline; it's not the same as having good code architecture. You can self-review a PR meticulously and still have architectural problems that reviewers should catch. The point is to remove distractions and show respect for the reviewer's time.

Key takeaways

• Review your own PR on GitHub before requesting reviews—read the full diff like you're seeing it for the first time
• Remove all debug code, commented lines, and temporary scaffolding that doesn't belong in the repository
• Add comments that explain why decisions were made, especially for non-obvious logic, constraints, or workarounds
• Verify that tests pass locally and include screenshots or output demonstrating the change works as intended
• Self-review is a habit that signals professionalism and respect for your team's time—it reduces back-and-forth and friction in the review process