The Code Review That Made Me Quit (And Why I Came Back)
127 comments. ‘This is garbage’ as the first line. I closed my laptop and walked out. Three months later, I realized he was right.
The Pull Request That Changed Everything
I remember the exact time I submitted that pull request: 4:47 PM on a Thursday.
I’d spent three weeks building a new feature. User authentication with OAuth, password reset flows, email verification — the whole nine yards. It was the biggest feature I’d built since joining the company six months earlier.
I was proud. Really proud.
The code worked. Tests passed. I’d even added some extra validation that wasn’t in the original spec. I hit “Create Pull Request” with a smile on my face, expecting maybe a few minor comments, a couple of nitpicks, and then approval.
I went home that night feeling accomplished. Tomorrow, I thought, this thing ships.
Tomorrow, I learned what it feels like to have your work torn to shreds.
Friday Morning: The Notification That Broke Me
My phone buzzed at 8:23 AM. GitHub notification. Code review from Marcus, our tech lead.
I opened it at a red light. Big mistake.
127 comments.
My stomach dropped.
I pulled into the office parking lot and sat in my car, reading through the review on my phone. My hands were shaking.
The very first comment, on line 1 of my PR description:
“This is garbage. Did you even read our coding standards?”
I stared at that sentence for what felt like five minutes.
Not “This needs work.” Not “Let’s discuss the approach.” Just: “This is garbage.”
I scrolled down. It got worse.
On my authentication logic:
“This is the most naive implementation I’ve ever seen. A junior bootcamp student would know better.”
On my error handling:
“Exception swallowing everywhere. Are you trying to hide bugs or just don’t understand how errors work?”
On my variable naming:
“passwordResetTokenExpirationTimeInMilliseconds? Seriously? This isn’t Java circa 2003.”
On my code structure:
“500-line functions. No separation of concerns. This looks like you learned programming from a YouTube tutorial.”
On my tests:
“These aren’t tests. These are wishful thinking. Not a single edge case covered.”
Every. Single. Comment. Had that tone.
Not constructive. Not educational. Just… mean.
By comment #47, I was crying in my car. By comment #89, I was angry. By comment #127, I was done.
I walked into the office at 9:15 AM. Went straight to Marcus’s desk.
“Can we talk?”
“About your PR? Yeah, I left some feedback.”
“Some feedback? You called my work garbage.”
“Because it is. Did you actually read the comments or just count them?”
“I read enough.”
“Then fix it.”
I stared at him. He stared back. No apology. No acknowledgment that maybe, just maybe, he’d been harsh.
I went back to my desk. Opened Slack. Typed a message to HR:
“I’m taking a personal day. I’ll be back Monday.”
I closed my laptop, walked out, and spent the rest of Friday alternating between anger, shame, and job-searching on LinkedIn.
The Weekend of Rage and Reflection
That weekend was a blur.
Friday night: Rage. I was the victim. Marcus was an asshole. The company was toxic. I deserved better.
Saturday: I started looking at other code reviews in our repo. Reading Marcus’s comments on other people’s PRs.
Something shifted.
His comments on other PRs were harsh too. But they were also… right.
I found a PR from another developer where Marcus wrote:
“This endpoint has no rate limiting. What happens when someone hits this 1000 times a second?”
The developer had replied: “Good catch. Added rate limiting.”
Marcus: “Also, you’re loading the entire user table into memory here. This will fail at scale.”
Developer: “You’re right. Changed to pagination.”
The comments were blunt. But they were catching real problems. Serious problems.
I looked back at my PR with fresh eyes.
His comment about naive authentication? I’d stored passwords in plain text in the logs. For debugging. I was going to “remove it later.”
His comment about exception swallowing? I had try-catch blocks that caught exceptions and did nothing with them. Just catch (Exception e) { }. Everywhere.
His comment about 500-line functions? My main authentication function was 487 lines. It handled OAuth, password resets, email verification, and session management. All in one function.
His comment about tests? I tested the happy path. That’s it. No edge cases. No error conditions. No boundary testing.
Sunday morning, I started refactoring. Not because Marcus told me to. Because I was seeing it now.
I split the 487-line function into 12 smaller functions. Added proper error handling. Removed the password logging (what the hell was I thinking?). Wrote actual tests.
By Sunday evening, I had 312 lines of code that did the same thing my original 1,847 lines did. And it was better. Cleaner. More maintainable.
Monday morning, I pushed the changes. Added a comment to the PR:
“Refactored based on feedback. You were right about everything.”
Marcus approved it in 20 minutes. No sarcasm this time. Just:
“Good work. This is production-ready.”
I should have felt relieved. Instead, I felt embarrassed. And angry. And confused.
The Conversation That Changed My Perspective
I avoided Marcus for three days. Then he cornered me in the kitchen.
“You’ve been weird since the code review.”
“Yeah, well, you called my work garbage.”
“I did. Because it was.”
“You could’ve been nicer about it.”
“Probably. But would you have actually fixed it if I’d said ‘This looks good but maybe consider these suggestions’?”
I opened my mouth to argue. Then I thought about it.
Honestly? Probably not. I would’ve made a few minor changes and shipped it. The password logging would’ve stayed. The 487-line function would’ve stayed. The missing error handling would’ve stayed.
And then, in production, when something broke — and it would have — I would’ve been the one debugging at 2 AM trying to figure out why authentication was randomly failing.
“I don’t know,” I admitted.
“Look,” Marcus said, “I’m not trying to be an asshole. I’m trying to keep bad code out of production. Because when that bad code breaks — and it will — it’s not your problem anymore. It’s everyone’s problem.”
“But the way you said it — “
“I know. I’m not good at the whole ‘gentle feedback’ thing. I’ve been doing this for 15 years. I’ve seen the same mistakes over and over. Naive auth implementations that leak credentials. Exception handling that hides bugs. Functions so big nobody can understand them. And every time, the developer who wrote it is long gone when it breaks. The team that has to fix it suffers.”
He paused.
“I’d rather hurt your feelings now than watch you ship code that hurts users later.”
I didn’t know what to say to that.
“Plus,” he added, “you actually fixed everything. Most people just argue. You did the work. That’s why I approved it.”
Three Months Later: The Same Situation, Different Side
Three months later, I was reviewing a junior developer’s PR.
Her feature looked good. Worked great in dev. Tests passed.
I started writing comments:
“This looks good, but — “
I stopped.
I looked at her code again. Really looked at it.
- SQL injection vulnerability in three places
- No input validation
- Hardcoded credentials (she’d commented “// TODO: use env vars”)
- A 600-line function
- No error handling
She was about to make the exact same mistakes I’d made.
I deleted my comment. Started over.
“This has several critical security issues that need to be fixed before this can ship.”
I listed them. All of them. With examples of how they could be exploited.
I didn’t say “This is garbage.” But I also didn’t sugarcoat it.
She messaged me an hour later: “Is it really that bad?”
“Yeah. But it’s fixable. Want to pair on it?”
We spent two hours refactoring together. I showed her how SQL injection works. How to validate input. How to break big functions into smaller ones.
At the end, she said: “I almost cried when I saw all those comments.”
“I know. I’ve been there.”
“But you’re right. All of it. I was about to ship a security nightmare.”
That’s when it clicked for me.
What I Learned About Code Reviews (The Hard Way)
Lesson 1: Harsh Feedback Hurts. Bad Code in Production Hurts More.
Marcus’s comments stung. But you know what stings more? Getting paged at 3 AM because your naive authentication implementation let someone brute-force into user accounts.
The sting of a code review lasts a day. The sting of a production incident lasts forever.
Lesson 2: If You Can’t Handle the Feedback, You Can’t Handle the Consequences
When my code review came back with 127 comments, I took it personally. I felt attacked.
But code isn’t personal. It’s not your baby. It’s not your identity.
Code is infrastructure. When it fails, people suffer. The feedback you get in a code review is nothing compared to the feedback you get from angry users, lost revenue, and embarrassed executives.
Lesson 3: The Best Reviewers Are The Ones Who’ve Seen It Break
Marcus was harsh because he’d lived through the consequences of bad code.
He’d been paged at 2 AM for a SQL injection vulnerability.
He’d watched a 500-line function bring down production because nobody could debug it fast enough.
He’d seen credentials leak into logs and cost the company a security audit.
His harshness wasn’t cruelty. It was pattern recognition.
Lesson 4: “Nice” Reviews That Approve Bad Code Aren’t Nice
In my next job, I worked with a tech lead who approved everything.
“Looks good!” on PRs with obvious bugs.
“Nice work!” on code that would clearly fail at scale.
“Ship it!” on features with no error handling.
You know what happened? Production broke constantly. Deployments were terrifying. Nobody trusted the codebase.
“Nice” reviewers who don’t push back aren’t being kind. They’re being negligent.
Lesson 5: The Goal Isn’t Feelings. It’s Quality.
Yes, feedback should be constructive. Yes, you should explain the “why” behind your comments. Yes, there’s a difference between “This is garbage” and “This approach has these specific problems.”
But the goal of code review isn’t to make people feel good. It’s to catch bugs, improve quality, and teach better practices.
Sometimes that’s uncomfortable. That’s okay.
The Code Review Culture Nobody Talks About
Here’s the uncomfortable truth about code reviews in tech:
Most companies have terrible code review culture.
I’ve worked at 5 companies now. Here’s what I’ve seen:
Company 1: Rubber-stamp reviews. Everyone approves everything. Production is chaos.
Company 2 (where Marcus worked): Harsh but effective reviews. Feelings get hurt. Code quality is excellent.
Company 3: Reviews that take 2 weeks. PRs pile up. People merge without approval just to ship.
Company 4: Passive-aggressive comment wars. PRs become political battlegrounds. Nothing gets done.
Company 5 (current): Balanced reviews. Clear standards. Fast feedback. Respectful but direct.
Guess which one ships the best code? Company 2.
Guess which one has the happiest developers? Company 5.
But here’s the thing: Company 5 only exists because the CTO came from Company 2. He learned from Marcus. He took the directness and added respect. He kept the high standards and removed the harshness.
You can have both.
What Good Code Review Actually Looks Like
After 4 years and hundreds of code reviews (given and received), here’s what I’ve learned:
Good Reviews Are:
✅ Specific
- Bad: “This is wrong”
- Good: “This query will cause a full table scan. Add an index on user_id.”
✅ Educational
- Bad: “You don’t understand async”
- Good: “This await is unnecessary because we’re not using the result. Consider removing it or adding error handling.”
✅ Actionable
- Bad: “This needs work”
- Good: “Extract lines 47–89 into a separate function. It’s doing input validation which should be separate from business logic.”
✅ Prioritized
- Critical: “This has a SQL injection vulnerability”
- Important: “This will fail at scale”
- Nice-to-have: “Consider renaming this variable for clarity”
✅ Focused on the Code, Not the Person
- Bad: “You clearly don’t know what you’re doing”
- Good: “This implementation doesn’t handle error cases. Here’s why that matters in production.”
Bad Reviews Are:
❌ Vague
- “This doesn’t feel right”
- “I don’t like this approach”
- “This could be better”
❌ Personal
- “Are you even a real developer?”
- “Did you learn programming yesterday?”
- “This is embarrassing”
❌ Bikeshedding
- 20 comments about variable naming
- Arguments about spaces vs tabs
- Debates about bracket placement
❌ Theoretical
- “What if we need to support 1 billion users?”
- “In a microservices architecture, this would…”
- “Google does this differently”
❌ Inconsistent
- Approving the same mistakes in different PRs
- Enforcing rules that don’t apply to senior devs
- Changing standards randomly
How to Survive Harsh Code Reviews
Because you will get them. Especially early in your career.
1. Separate Your Ego from Your Code
Your code is not you. A critique of your code is not a critique of your value as a human.
Bad code doesn’t make you a bad person. It makes you a person who wrote bad code. Today.
Tomorrow, you’ll write better code.
2. Look for the Signal in the Noise
Even harsh reviews usually contain valid points.
Marcus called my work “garbage,” but he also pointed out 127 specific problems. I could focus on the word “garbage” or I could focus on the 127 ways to improve.
I chose wrong the first time. I chose right the second time.
3. Ask Questions
If a comment doesn’t make sense, ask.
“Can you explain why this is a problem?” “What would a better approach look like?” “I don’t understand this suggestion. Can we pair on it?”
Good reviewers will explain. Bad reviewers will… well, you’ll know they’re bad reviewers.
4. Fix It, Then Reflect
When you get harsh feedback, your instinct is to defend your choices.
Don’t.
Make the changes first. Then, once the emotion has passed, reflect on whether the feedback was fair.
I’ve found that 90% of harsh feedback is correct. The delivery sucks, but the content is valid.
5. Remember: They’re Trying to Help (Usually)
Most reviewers aren’t trying to hurt you. They’re trying to protect the codebase.
They’ve seen bad code cause outages. They’ve been paged at 3 AM. They’ve spent weeks debugging someone else’s mess.
Your PR is not special. It’s potential technical debt, just like every other PR. Their job is to make sure it’s good debt, not bad debt.
The PR That Made Me A Better Developer
You know what’s funny? That PR Marcus destroyed wasn’t my best work. It was actually my worst work.
But the refactored version? That became the template for how we did authentication across the entire company.
Three other teams adopted the pattern. New hires studied it as an example of “how we do things here.”
That never would have happened if Marcus had said “Looks good, ship it.”
I needed those 127 comments. I needed to feel uncomfortable. I needed to learn that “working code” isn’t the same as “good code.”
Why I Came Back (And Stayed)
I almost quit that day. I had the resignation letter drafted. I was ready to walk.
But something stopped me.
I realized: I wasn’t mad at Marcus. I was mad at myself.
I was mad that I didn’t know what I didn’t know.
I was mad that I’d been proud of code that was, objectively, garbage.
I was mad that I’d spent six months at this company and still had so much to learn.
But that’s exactly why I needed to stay.
I could go to a company where everyone approved my PRs and told me I was great. I’d never grow.
Or I could stay somewhere that pushed me, challenged me, and made me better. Even if it hurt.
I chose to stay.
Best decision I ever made.
Four Years Later
I’m a senior engineer now. I’ve reviewed thousands of PRs. I’ve given harsh feedback. I’ve received harsh feedback.
And I’ve learned this:
The developers who take criticism and improve become great engineers.
The developers who defend every line of code they write stay mediocre forever.
Marcus was harsh. Sometimes too harsh. But he was also right.
And I’d rather work with someone who tells me the truth bluntly than someone who tells me comfortable lies.
Your code will be reviewed. Sometimes harshly.
You can take it personally and quit.
Or you can fix the code, learn the lesson, and become better.
I’m glad I chose the second path.
When Code Reviews Go Wrong (And How to Fix Them)
Look, code reviews are hard. Whether you’re giving them or receiving them, you’re gonna mess up sometimes.
If you want to get better at both sides of this, I turned years of code review mistakes into something useful:
📋 For dealing with production consequences:
👉 Production Incident Survival System — What to actually do when your code breaks production (and how to survive the post-mortem)
Production Incident Survival System
👉 Backend Failure Playbook — Real failures that started with code reviews that missed critical issues
The Backend Failure Playbook How Real Systems Break and How to Fix Them (Java, Spring, SQL, Cloud)
🎓 For leveling up your code quality:
👉 Master Git in Minutes — Because half of code review issues are actually Git issues in disguise
Master Git in Minutes – 35 Essential Commands & Real-World Workflows
These aren’t “how to write nice comments” guides. They’re field manuals for what actually happens when code review goes wrong.
Use them if you want to avoid learning these lessons at 3 AM on a Friday.
I Write About What Actually Happens in Engineering
No motivational BS. No toxic positivity. Just real stories from the trenches.
👉 Free here:
Devrim’s Engineering Notes | Substack
You’ll get:
- Code review disasters (and wins)
- Production incidents that started with a missed review
- Career lessons learned the expensive way
- No AI fluff, no sponsored content, no lies
Join 5,000+ engineers who are tired of LinkedIn fairy tales.
Got a code review horror story? Drop it in the comments. We’ve all been on both sides of harsh feedback. Let’s learn from each other’s battle scars.
Thinking about quitting over a bad review? Read this post again in 24 hours. The code review might be harsh. It might even be unfair. But ask yourself: is the feedback technically correct? Because if it is, that’s the review doing its job.
Now go write some better code. And when someone tears it apart, remember: they’re not attacking you. They’re attacking bugs you haven’t found yet.
Your future self — the one who doesn’t get paged at 3 AM — will thank them.
The Code Review That Made Me Quit (And Why I Came Back) was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More