What you'll learn
Quick Answer
Keep pull requests small and single-purpose, write a description explaining why rather than what, and review your own diff before requesting review. Small PRs get reviewed in minutes; large ones get postponed.
Size decides everything
The most reliable predictor of how fast a pull request is reviewed is how large it is, and the relationship is not linear.
A 50-line change gets reviewed properly during a coffee break. A 900-line change requires a reviewer to clear an hour, understand a large amount of context, and hold it all in their head — so it gets postponed. Then it conflicts with main, needs rebasing, and grows.
Large pull requests also get worse reviews. Beyond a few hundred lines, reviewers skim, comment on trivia they can evaluate quickly, and approve. The bugs pass through.
Practical splitting strategies:
- Separate refactoring from behaviour change. A diff mixing a rename across forty files with one logic change is unreviewable. Do the rename, merge it, then change behaviour — see refactoring basics.
- Ship in stages. Backend first, then the interface. Behind a flag if needed.
- Split by layer or feature, each independently mergeable.
Write the description for someone with no context
The diff shows what changed. Only you can explain why.
A description worth reading covers: the problem, the approach, anything the reviewer should look at closely, and how it was tested.
Problem: Users could book the same slot twice if they clicked at the same moment. Reported twice this week.
Approach: Moved the availability check inside the transaction that writes the booking, so the row is locked between check and write. Considered an application-level lock but that fails with multiple servers.
Worth a look: the isolation level in
booking_repository.py— I have not used SERIALIZABLE here before.Testing: added a concurrent test that reproduced the bug before the fix and passes after.
That takes three minutes and saves the reviewer twenty. It also flags where you are uncertain, which is exactly where review is most valuable.
Include a screenshot or short recording for any visual change. It is far faster than reading CSS.
Review your own diff first
Open the Files Changed tab and read it as though someone else wrote it, before requesting review. This consistently catches:
- Debug prints and commented-out code.
- Files you did not mean to commit —
.env, editor settings, build output. - Unrelated formatting churn that inflates the diff.
- Half-finished renames and leftover TODOs.
Leaving your own comments on the diff is even better. Explaining a non-obvious decision inline pre-empts the question, and marking "not sure about this approach — thoughts?" directs attention where you want it.
Make sure CI is green before requesting review. Asking someone to review code that does not pass its own tests wastes their time and yours.
Responding to feedback
The part that shapes how people experience working with you.
Assume good intent. Review comments are about the code. "This will break when the list is empty" is information, not criticism.
Answer every comment, even if only to acknowledge. A silently resolved thread leaves the reviewer unsure whether you agreed or missed it.
Push back when you disagree, with reasoning. "I considered that, but it would break X — happy to change if you still prefer it" is a good response. Reviewers are frequently missing context you have.
Distinguish blocking from optional. If you are reviewing, mark preferences as such — "nit: " is the common convention. Nothing stalls a pull request like ambiguity about whether a style preference must be addressed.
Move long discussions off the thread. Three rounds of back-and-forth means a five-minute conversation would be faster, then record the outcome in a comment.
Pull requests to projects you do not own
Different rules, and ignoring them is why first contributions often go nowhere.
- Read CONTRIBUTING.md first. It exists precisely so maintainers do not repeat themselves.
- Open an issue before a large change. Building a substantial feature unannounced and opening a pull request frequently ends in rejection — not because the code was bad, but because it did not fit plans you could not see.
- Match the existing style rather than importing your preferences.
- One concern per pull request. Maintainers cannot accept a change bundled with three unrelated ones.
- Be patient. Maintainers are usually volunteers. One polite follow-up after a couple of weeks is reasonable.
A merged pull request to a real project is disproportionately strong evidence for a fresher — it demonstrates working in an unfamiliar codebase and accepting review, which is much of what a junior job involves. See what recruiters look at on your GitHub.