Why Code Review Feels Like a Trial (And What It Costs Your Team) | by Tuğhan Belbek | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in
Medium Logo
Get app<br>Write
Search
Sign up<br>Sign in
Press enter or click to view image in full size
Why Code Review Feels Like a Trial (And What It Costs Your Team)
Tuğhan Belbek
6 min read·<br>Just now
Listen
Share
The most experienced engineers in your team are also the most hesitant to show their work.<br>I watched a staff engineer stare at a pull request for 45 minutes last month.<br>Not reviewing someone else’s code. His own.<br>He kept rewriting the commit message. Refactoring a function that already worked. Checking if anyone was online before he clicked submit.<br>This is a person with 12 years of experience. And he was nervous about a code review.<br>The Numbers Nobody Talks About<br>52.7% of software engineers experience frequent to intense levels of imposter phenomenon [1].<br>That is not a fringe group. That is more than half the people writing the software you use every day.<br>The study, published on arXiv in late 2023, surveyed working engineers and found the phenomenon cuts across experience levels [1]. Junior developers feel it because they are new. Senior developers feel it because they are supposed to know everything.<br>The expectation changes, but the feeling does not.<br>A separate study at a major tech company surveyed 1,317 developers about their code review experiences [2]. The researchers were studying process efficiency. What they found was a pattern of negative emotional responses tied directly to review feedback. Developers with more seniority reported higher anxiety about public critique, not lower.<br>The more you are supposed to know, the more it stings when someone suggests you do not.<br>Why Senior Developers Feel It More<br>Here is the paradox that breaks the usual narrative.<br>Junior developers expect to learn. They ask questions. Senior developers have spent years building a reputation. Their credibility is their currency. Every public interaction is a transaction.<br>A 2017 Forbes analysis of the Dunning-Kruger effect in tech found that 32–42% of software engineers rated their skills in the top 5% of their companies [3]. Think about that math. If 40% of people think they are in the top 5%, most of them are wrong. But the people who are right about being in the top 5% are surrounded by people who are wrong. They see the overconfidence daily. And it makes them doubt themselves.<br>The most competent people often have the most accurate self-assessment. They know exactly how much they do not know. That awareness is a feature of expertise. But it feels like a bug when you are trying to lead a team.<br>The Code Review Problem<br>Google spent two years studying 180 teams to figure out what makes them effective.<br>Their Project Aristotle found that psychological safety was the single strongest predictor of team performance [4]. More than talent. More than resources. More than experience.<br>Amy Edmondson at Harvard had found this years earlier in hospital teams. The teams that reported the most errors performed the best. Not because they made more mistakes. Because they felt safe enough to talk about them [5].<br>Code review is where this plays out in software.<br>It is supposed to catch bugs. Instead, it often catches people.<br>A developer I know described it like this: “Every comment feels like a scorecard. Not on the code. On me.”<br>That is not what review is for. But that is what review becomes when the culture around it treats feedback as evaluation instead of collaboration.<br>What Fear Actually Costs<br>This is where it stops being a personal problem and starts being a business problem.<br>Workplace stress costs U.S. businesses approximately $300 billion annually in lost productivity [6]. Organizations with high fear cultures experience 55% higher turnover and measurably lower innovation output [7]. Fear-based leadership alone costs an estimated $36 billion annually [8].<br>But the numbers that do not show up in reports matter more.<br>The senior engineer who stops proposing architectural changes because the last one got picked apart in a public Slack thread. The tech lead who stops mentoring juniors because explaining their reasoning feels like defending a dissertation. The staff engineer who writes perfect, boring code because interesting code attracts interesting criticism.<br>These are not lazy people. These are careful people. And careful people, in the wrong culture, become quiet people.<br>The Cost to Everyone<br>For the individual, the cost is quieter but no less real.<br>Burnout accelerates. The constant vigilance of managing your reputation is exhausting. A Haystack study found 83% of developers experience burnout [9]. Learning slows down. When showing weakness feels risky, you stop asking questions. Career growth stalls. Fear makes you invisible. The people who get promoted are often the most visible, not the most skilled.<br>Mental health suffers. A Stack Exchange thread where a developer wrote about living in fear...