Review Your Own Pull Request First!

Why you should review your own Pull Request first to catch design issues, typos and logic gaps before teammates see them. What difference does it make?

Jan 15, 2025

Like most developers, I’ve been on both sides of Pull Requests (PRs) - sending them out to colleagues and reviewing others’ code in a sprint to meet deadlines. What I’ve noticed is that the best PRs, the ones that get merged smoothly and with minimal back-and-forth, are the ones where the author has already done a thorough self-review. It’s not just about tidying up code style; it’s about catching design flaws, typos, logic gaps and potential optimisation pitfalls before your teammates do.

In this post, I’d like to walk through why you should review your own PR first and provide some practical steps on how to do it. And hey, I’m writing this because I’ve personally seen the difference it makes while building internet-scale fintech systems for Europe; where a missed detail can lead to big headaches down the line.

1. Why Self-Review Is Critical

a. Saves Time for Everyone

As soon as you open a Pull Request, your teammates set aside time to look at your code. If your PR is full of small mistakes; like typos, unused variables (although unlikely to happen with languages like Go - my primary & favorite programming language), or dead code - reviewers will end up focusing on these easy catches instead of more architectural or design concerns. By cleaning up these obvious issues yourself, you let reviewers zero in on what really matters.

Personal note: Very early in my career, I once rushed a PR for a critical feature and ended up with a barrage of comments about redundant code and inconsistent naming. About 30 of them. The real logic flaw I introduced got overlooked for a while - until it blew up in staging.
Embarrassing? Yes. It taught me that even a quick self-review can spare everyone a lot of pain later.

b. Improves Your Own Code Quality

Reading your own code diff is like stepping back to observe your painting from a distance. You notice patterns (or anti-patterns) that don’t jump out when you’re in the trenches writing code. Did you name that function well? Is there an awkward datastructure that might be simplified? These insights not only refine your current PR but also shape how you approach coding in the future.

c. Builds Trust and Professionalism

Whether you’re working in a small startup / scaleup (like where I do) or a large enterprise, your PR is a reflection of your work ethic. Taking time to polish your code before asking for a review signals respect for your colleagues’ time. Over multiple sprints, that respect fosters trust and leads to more streamlined team communication.

2. How to Perform a Self-Review

a. View the Diff As If You’re Someone Else

I usually open GitHub (GitLab, or Bitbucket in your case), navigate to the Files changed tab, and read every line as though I’m the reviewer. Are the naming clear? Is error handling consistent (which is a MUST with Go) ? Is there test coverage for every new or changed piece of logic? (You can be a conservative, but not here). By shifting perspective, you’ll catch issues you missed while coding.

Real story: In a FinTech context, especially with microservices for accounts, transactions or credit cards, a single nil check might prevent a major production outage. Reading the diff as a reviewer helps me see if I’ve handled edge cases; like a missing value in a 3rd-party API response.

b. Check Commit Messages and Branch Name

Yes, your PR title and description are important, but so are your commit messages. They form a living history of your project. Does it follow (try to) the conventional-commit style? Does each commit represent a logical chunk of work? Or do you see “WIP: fix bug” repeated four times?

Atomic Commits: Make sure each commit fixes or implements exactly one thing.
Good Commit Messages: Follow a structure like fix: handle missing field in transaction flow, rather than “misc changes”.

If you spot multiple fixes or refactors jammed into one commit, consider an interactive rebase to split them up. Similarly, ensure your branch name follows your team’s convention (like JIRA-5678-fix-transaction-timeout) to keep things organized.

c. Document Any Special Considerations

If there’s something non-obvious about your approach; for example, a tricky concurrency (??!!) hack or a workaround for a known library bug - mention it. Add inline comments in your code or elaborate in your PR description. Your Oncall Engineer will thank you while firefighting a production issue at 3 AM.

Tip: If your code references a known bug or limitation, link to any relevant tickets or documentation right in the PR or code comment. Clarity now saves major confusion later.

d. Validate Tests and Benchmarks

Every new or modified code path should ideally have a test - unit, integration or end-to-end. Quickly run them locally (or rely on CI if it’s robust enough) and check coverage reports if available. Did you add new database migration script or an additional endpoint? Make sure you’ve tested for both success and failure scenarios.

From experience: In a microservice handling accounts or transactions, a single missed test case might break the ledger for an entire day. Tests aren’t just checkboxes; they’re safety nets.

e. Check for Style and Linting

Even small inconsistencies in code style can distract reviewers from more substantial issues. If your team uses linting tools or formatters like golangci-lint, gofumpt or ESLint, run them before you open a PR. Fix any warnings or errors unless they’re truly exceptions to your rule set.

3. Common Pitfalls (And How to Avoid Them)

Too Large PRs
- Solution: If you find your PR has grown too large, consider breaking it into smaller chunks. Maybe the database schema migration script can (in ideal cases - SHOULD) be a separate PR.
Neglecting Documentation
- Solution: If your changes include a new API endpoint or config file, update the README or relevant docs. Reviewing your own PR is a great time to spot missing documentation.
Lack of Context in the PR Description
- Solution: Summarize what changed, why it changed, and any impacts on the system. This ensures the reviewers understand the context from the get-go.
- Another one: I have a habit to add PR comments pointing to my code explaining tricky bits or why I made a certain decision. It helps me think things through and makes it easier for reviewers to quickly grasp the rationale behind my decision later on.
Forgetting to Rebase or Merge Main
- Solution: Before you finalize your PR, pull in the latest changes from main or develop (depending on your workflow). Fix any merge conflicts now rather than letting your reviewer handle them.

4. The Ripple Effect of a Good Self-Review

a. Faster Approvals

If your PR is clean and well-structured, your reviewers won’t have to spend time on trivial comments or guess your intentions. This leads to a more constructive review session where you can focus on potential design improvements and edge cases, ultimately speeding up merges.

b. Better Team Morale

Pull requests often come with a bit of stress; nobody wants that dreaded “Can you fix these 17 things?” comment. A well-reviewed PR shows you respect the review process, which makes your teammates more eager to review your work. This mutual respect boosts morale and reduces the friction sometimes found in code review cycles.

c. Stronger Codebase for Production-Grade Systems

In FinTech or any high-stakes industry, code reliability is paramount. Errors can be costly - financially and reputationally. By catching small bugs and questionable logic early, you reduce the risk of these issues making their way to production.

A personal anecdote: I remember we once traced a subtle floating-point rounding bug that only appeared in large batch transactions. Had I done a thorough self-review, I think I might’ve caught it. Instead, we found out during a production spike, leading to a hotfix scenario.

5. Final Thoughts

PR reviews are not just a box to check or to rely on others to correct our mistakes; they’re a vital step in producing quality, maintainable software. By reviewing your own PR first - treating it like someone else’s code; you’ll create a better experience for both yourself and your reviewers. Think of it as a courtesy that doubles as a code-quality accelerator.

Thanks for reading! If you found this helpful, feel free to leave a comment or share your own stories. I’d love to hear how self-review has impacted your codebase or your team’s productivity.

Happy Coding — and Happy Reviewing!

For more content, please consider subscribing. See you in the next post!