The Bar That Already Has a VerdictYou open your own pull request before standup and the little bar reads +312 −89 in green and red. No one has commented yet, but you've already scored the match: too many lines touched, too much red, that must mean you broke something. The diff stat turns into a scoreboard, and you've mentally chalked up the loss before a single reviewer has opened a file.
OLD SCRIPT DETECTED
“The diff stats feel like a scoreboard I'm already losing”
Try this response:
“The plus-minus count measures lines moved, not how this review is going to go.”SEE THE PRACTICE
Build a response for this thought—and one move to prove it.
THE THOUGHT
“The diff stats feel like a scoreboard I'm already losing”
YOUR RECORDED RESPONSE
“The plus-minus count measures lines moved, not how this review is going to go.”
ONE PRIVATE MOVE
Open a pull request you merged months ago with a diff stat you remember dreading, and count how many comments mentioned size versus what the code actually did.
The Green-Red Bar I Read Like a Scorecard
Two Rigged Dials Under the BarResearch on code review anxiety found this reaction runs on two dials tilted the same direction: one predicts the review will go badly, the other treats a rough review as proof of what you are, not just the code. Stack a large diff on top of that pairing and a plain count of changed lines starts reading like a scoreboard instead of what it actually measures, which is how much code moved.
Pulling One Old Scoreboard Back UpTonight, open a pull request you merged months ago, one whose diff stat you remember dreading at the time. Count how many comments actually addressed the size of the change versus how many addressed what the code did. One old thread won't retire the pattern for good, but it hands you a real count to weigh against the score you've been keeping in your head.
TRACE · 01/04
How this script runs you
- You refresh a pull request before any comment lands, reading the plus-and-minus count like a running score you're already behind on.
- A diff with more red than green feels like proof you gutted something, even when the deleted lines were dead code you meant to remove.
- You mentally rank your own pull requests against teammates' by line count, as if whoever touched fewer lines is quietly winning.
SOURCE_LOCATED · 02/04
The hidden rule underneath
The Review Trial
If my diff stat shows a high line count, that number is already scoring me before review even starts, so a small diff means I'm ahead and a large one means I've already lost.
FORGING_REPLACEMENT · 03/04
Replacement lines (record these)
- The plus-minus count measures lines moved, not how this review is going to go.
- A big diff isn't a losing score, it's just more surface for someone to check.
- I read the stat once, then I read the actual comments; those are two different reports.
Generated per person in the app — these are the flavor, not your script. Yours is built from your exact words.
INSTALL · 04/04
The protocol, on one card
When I think
“The diff stats feel like a scoreboard I'm already losing”
I say
“The plus-minus count measures lines moved, not how this review is going to go.”
Then I do one thing
Open a pull request you merged months ago with a diff stat you remember dreading, and count how many comments mentioned size versus what the code actually did.
STATUS: READY_TO_INSTALL
Wipe this thought4 minutes. Your voice. Free.
The wipe protocol
- Write the thought exactly as it plays: "The diff stats feel like a scoreboard I'm already losing". Word for word — the wipe targets the sentence, not the vibe.
- Trace the rule and the avoided action. What does this thought conveniently excuse you from doing?
- Record the replacement lines below in your own voice. Speak like you mean it — no recording, no install.
- Run the loop: play it every morning and night, log one proof action a day for 7 days.
Straight answers
Does a bigger plus-minus count actually predict a harsher review?
Not reliably. A large diff stat tells a reviewer how much surface there is to look at, not how they'll judge it. Plenty of big diffs get quick approvals because the change is mechanical, and plenty of small ones draw long threads because the logic is subtle.
What if my diff really does show far more red than green, mostly deletions?
A deletion-heavy diff usually means cleanup, consolidation, or removing something that no longer earns its place, not damage. Reviewers read deleted lines as fewer things to maintain later, which is closer to a relief than a verdict against you.
Should I split every large pull request into smaller ones just to dodge the scoreboard feeling?
Splitting can make a change easier to review, but it won't cure the habit of scoring yourself by line count, since the feeling can attach itself to whatever diff is in front of you next, large or small. It's worth doing for clarity, not as an escape from the count.
Related old scripts
Related self-checks
Related science
Researchers to explore
Related mechanisms
The research behind this script
- Impostor Phenomenon in Software Engineers — Guenes et al., ICSE-SEIS 2024, 2024
- Understanding and effectively mitigating code review anxiety — Lee et al., Empirical Software Engineering, 2024
- Understand team effectiveness (Project Aristotle) — Google re:Work, 2016
- Psychological impacts of AI-induced job displacement among Indian IT professionals: a Delphi-validated thematic analysis — PMC, 2024