Good code review advice doesn't come from threads with đ in them

Table of contents
- Bad code review trend #1: The âJust merge itâ mentality
- Bad code review trend #2: âCode reviews are for juniorsâ
- Bad code review trend #3: âNitpicks are toxicâ
- Bad code review trend #4: Frequently turning code reviews into a performance (aka the live review trap)
- Bad code review trend #5: Not reading through your AI-code first
- Code review etiquette: How to be a code reviewer people want to work with

Code reviews used to be a quiet, dignified affairâan async ritual where you thoughtfully (or passive aggressively) gave feedback and occasionally dropped a ânit: maybe rename this var?â comment to feel alive. But then social media got involved. Now, developers are sharing hot takes about code reviews, many of which sound like they were written by someone whoâs never met another human being.
In one corner, we have Twitter influencers claiming you should âjust merge it and fix it laterâ because iteration (and downtime) is life, apparently? In another, LinkedIn grindset bros are insisting that real devs donât need code reviews because âyou should trust your team.â
And then thereâs the advice that seems like trauma disguised as tradition: âOur team just roasts each otherâs code live on Fridays. It builds character.â Or: âWe only do in-person code reviews, it keeps people honest.â Translation: weâve replaced the comments section with live humiliation. Bold strategy.
To illustrate the impact of influencers on development cycles, we created a comic. The Battle of the Bathrobe Influencers playfully pokes fun at some of our favorite influencers and how many different code review takes there are on the timeline right now and how that might affect individual developers if teams actually listened to and followed all the competing takes. No influencers were harmed in the making of this comic⌠we hope.
At CodeRabbit, we love a good code review etiquette debate but we also like shipping code and keeping our coworkers emotionally intact. So, weâve put together a list of some code review bad takes weâve seen floating around the timelineâand what to do instead if you donât want your team quietly scheming your removal from the repo.
Bad code review trend #1: The âJust merge itâ mentality
If you've ever seen a pull request titled âWIP â just gonna merge this for now,â youâve met a âJust merge itâ dev. Theyâre disciples of the âmove fast and break literally everythingâ school of development. They believe in shipping code quickly no matter how bad is a strength and fixing things later is part of the agile lifestyle.
But hereâs what actually happens when you merge bad code to âfix laterâ: you donât fix it later. No one does. It goes to production. It breaks. Now your teammate is debugging a mystery bug on a Sunday night and slowly whispering your name like itâs part of a ritual curse.
If youâre trying to speed things up, hereâs a radical idea thatâs better than just merging it: review your own code before you ask someone else to. Give it a read with fresh eyes. Clean up nonsense logic, remove dead code, and maybe run it through an AI reviewer like CodeRabbit in your IDE so you donât miss something humiliating (like importing a library youâre not even using. Again).
Bad code review trend #2: âCode reviews are for juniorsâ
Another fun trend: the belief that once you hit âStaff Engineer IV (Ascended Form),â code reviews are beneath you. Youâve achieved such enlightenment that no mortal can possibly understand your code.
This mindset turns senior devs into unreviewable wizards who vanish into architectural side quests and return weeks later with 2,000-line PRs and the words âdonât worry, I tested it.â
Hereâs the truth: the more senior you are, the more important it is to have your code reviewed. Not because you donât know what youâre doing but because your work is more impactful, more complex, and more likely to become the terrifying foundation for everything built after it. If that code is flawed, future developers will suffer.
Plus, code reviews are a two-way street. Senior engineers can model how to give constructive feedback, share architectural context, and mentor others by writing thoughtful comments. They can also learn from junior devs who ask great questions or spot something weird because theyâre not desensitized to your obscure variable naming scheme yet. So, donât skip reviews. Normalize them at every level.
Bad code review trend #3: âNitpicks are toxicâ
Thereâs a growing movement online that says nitpicky comments in code reviews are basically microaggressions. That if you suggest someone rename a variable or break up a 30-line function, youâre stifling creativity and slowing down development for no good reason. Look, we get it. No one wants to receive 14 comments about whitespace and whether itâs âutilsâ or âhelpers.â But not all nitpicks are created equal.
The truth is, a lot of âtinyâ things in code arenât actually tiny. Theyâre death by a thousand readability cuts. Codebases rot from the inside out when no one sweeps up the small stuff. Confusing names, inconsistent structure, or one-off edge case handling eventually add up to a debugging experience best described as âpsychological horror.â
That said, nit-level feedback shouldnât feel like an attack. The goal isnât to flex your encyclopedic knowledge of the company style guideâitâs to help your teammate write code the next person (and the next-next person) can understand. You can do that without sounding like a passive-aggressive linter.
Start by offloading the basics to, well⌠actual linters. CodeRabbit, for example, comes with 30+ linters built in, so you donât have to waste brain cells correcting indentation or lecturing someone about semicolons. That frees you up to focus on logic, clarity, and architectureâthings humans are best at.
Bad code review trend #4: Frequently turning code reviews into a performance (aka the live review trap)
You know whatâs great about pull requests? You can review them in sweatpants at 10pm, covered in crumbs, muttering to yourself in peace if you want. You know whatâs not great? Being called into a surprise Zoom meeting where your manager shares their screen and says, âLetâs walk through your code together... as a team.â
Live code reviews are the latest workplace horror disguised as collaboration and âcontext sharing.â And sometimes they are! But often theyâre just a weird hybrid of interrogation and performance art. You sit there while someone scrolls through your functions like theyâre auctioning off your dignity and other devs chime in with helpful thoughts like, âYeah, I had questions about that, too.â
These sessions are especially rough for junior devs, introverts, or literally anyone who doesnât enjoy public code autopsies. They discourage honest feedback (because who wants to be the one to say âthis is confusingâ in front of the CTO?) and eat up everyoneâs calendars. What couldâve been solved with three async comments now requires a 45-minute meeting and an existential crisis.
There is a place for live code reviewsâbut itâs not âevery sprint, all the time.â Use them intentionally: for onboarding, gnarly architectural changes, or postmortems. And if youâre going to do one, give people a heads up.
Bad code review trend #5: Not reading through your AI-code first
As if things werenât chaotic enough in development, we now have AI entering the scene like a caffeinated intern who means well but keeps hallucinating entire modules. AI coding tools are powerful â but also deeply chaotic. Theyâll give you working code and sprinkle in a few imaginary functions for flavor.
Weâve seen it all: five-thousand-line PRs with variables named foo7, random timeouts, and logic that reads like someone asked ChatGPT to explain taxes using only metaphors. Sometimes it even compiles! But that doesnât mean your AI sidekick didnât also sneak in a few logic bugs, duplicate code blocks, or functions that only make sense if youâre a large language model yourself.
AI tools are here to help â not replace critical thinking. If your workflow is âvibe prompt, commit code, start lunch,â then yes: youâre part of the problem. Review what your AI assistant wrote. Refactor. Sanity check. And for the love of merge conflicts, run a local AI review before unleashing it on your team.
CodeRabbitâs AI reviewer in your IDE can catch a lot of issues before your teammates have to. Itâs like having a robot tell you your flyâs down before you walk into a meeting â deeply appreciated and MUCH less awkward than your boss doing it.
Code review etiquette: How to be a code reviewer people want to work with
Letâs say youâve made it through this blog post without recognizing yourself in any of these horror stories. You win! Now, letâs level up: how do you become the kind of reviewer people actually like getting feedback from?
Start by being human. Leave thoughtful comments that explain the why, not just the what.
Ask questions when somethingâs unclear instead of assuming malice or incompetence.
If somethingâs genuinely clever or elegant? Say so! A simple ânice workâ in a PR can be a game-changerâespecially when the rest of the comments feel like homework corrections.
It also helps to not sound like a compiler error in human skin. Use a friendly tone. Emojis are fine in moderation (a well-placed đ or đ goes a long way).
You can even sprinkle in a bit of humor, assuming your teammate isnât currently crying over merge conflicts â or maybe because they are and you want to make them laugh.
The golden rule of code review etiquette is simple: give the kind of feedback youâd want to receive. And maybe donât reply to every comment with a Notion doc defending your variable naming philosophy. Lifeâs too short.
Want an AI reviewer that wonât give bad advice? Try CodeRabbit in your IDE and git-platform.
Subscribe to my newsletter
Read articles from Emily Lint directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
