I need to get something off my chest. And honestly, I'm scared to write this. Because the tech community eats its own. But silence is complicity, so here we go.
Part 1: The Moment I Knew We Had a Problem
A few months ago. Slack notification. Code review channel.
A junior developer—let's call her Sarah—submitted her first major pull request. Three hundred lines of authentication logic she'd worked on for two weeks. She was proud. You could feel it in her commit message: "Finally got this working! 🎉"
The senior reviewer's first comment:
"Who taught you to code? This is a mess. Did you even Google 'how to structure a Node.js app' before writing this garbage?"
Sarah went offline. Didn't come back that day.
The next morning, she sent a DM to our manager: "I don't think I'm cut out for this."
I wanted to scream.
Because here's what nobody mentioned in that code review: Her code worked perfectly. It passed all tests. It was secure. It solved the problem.
It just didn't match the senior dev's personal preference for folder structure.
That's when I realized: we've built a culture where being "right" matters more than being kind. Where crushing someone's spirit is acceptable if you can justify it with a Medium article about "best practices."
And I'm fucking tired of it.
Part 2: Let Me Tell You What We've Normalized
Let me paint you a picture of what "normal" looks like in developer communities right now:
Twitter/X: Open any tech thread. Within five replies, someone's calling someone else an idiot. "You don't know JavaScript if you don't understand closures." "Real developers use Vim." "If you need TypeScript, you can't code."
Stack Overflow: A beginner asks a genuine question. Marked as duplicate. Closed. No link to the supposed original. Three comments telling them to "Google it." The person never asks another question.
Discord/Slack: Junior shares something they learned. Senior replies: "That's literally in the docs. Did you even read them?" (Narrator: The docs are 400 pages and poorly organized.)
Code Reviews: WTFs per minute. Condescending comments disguised as "feedback." Blocking PRs over semicolon placement while ignoring architectural issues.
Interviews: Algorithm hazing disguised as "assessment." Rejecting candidates who can build products but can't invert a binary tree on a whiteboard in 15 minutes.
We've normalized being assholes. We've wrapped it in the language of "maintaining standards" and "keeping quality high." But here's the truth:
Cruelty is not rigor. Gatekeeping is not quality control. Making someone feel stupid is not teaching.
And somewhere along the way, we decided that being a good developer means being a dick about it.
Part 3: How Did We Get Here?
I've been in tech for 10 years. I watched the culture shift.
It wasn't always like this.
Ten years ago, tech felt like a community of people excited to build things. We shared code. We helped each other. Stack Overflow answers were kind. "Here's how to do it, and here's why" was the standard response.
Then something changed.
The money arrived. Six-figure salaries. IPOs. Tech became glamorous. Suddenly, being a developer wasn't just a job—it was an identity. A status symbol.
And like any status symbol, people started protecting it.
"Not everyone should be a developer." "The industry is too saturated." "We need to raise the bar."
What they really meant: "I got here first, and I want to keep my advantage."
The bootcamps exploded. Career changers flooded in. Some were genuinely passionate. Some were chasing paychecks. But instead of welcoming new people and filtering for attitude and aptitude, we started hazing them.
"Real developers have CS degrees." "Bootcamp grads aren't real engineers." "You don't understand fundamentals."
The framework wars intensified. React vs Vue. Vim vs VS Code. Spaces vs tabs. Every choice became tribal. Every preference became dogma.
And God help you if you picked the "wrong" one.
The grind culture metastasized. Grinding LeetCode at 2 AM became a flex. "I built this over a weekend" posts everywhere. Side projects as penance. You're not a real developer unless you're coding 80 hours a week.
Burnout became a badge of honor instead of a warning sign.
The influencer era began. Tech Twitter personalities with massive followings. Every take had to be hot. Every opinion had to be strong. Nuance died. You're either a 10x engineer or a fraud.
And if you disagreed? "Clearly you don't understand."
Somewhere in that evolution, we lost our humanity.
Part 4: The Shame Machine
Let me explain how the shame works because it's systematic.
Stage 1: The Question
You ask a question in a public forum. You're stuck. You're frustrated. You need help.
Stage 2: The Immediate Judgment
"Did you even Google this?" "This is basic stuff." "Why are you asking us to do your homework?"
You feel stupid. You feel like you've wasted people's time. You apologize.
Stage 3: The Pile-On
Other people see the thread. They add their two cents. "Yeah, this is pretty fundamental." "You should know this if you're calling yourself a developer."
The shame compounds. You're not just stuck on a technical problem anymore—you're questioning whether you belong in this field at all.
Stage 4: The Internalization
You stop asking questions publicly. You suffer in silence. You spend hours debugging alone rather than risk being shamed again.
Your growth slows. Your confidence erodes. You start thinking: "Maybe I'm not cut out for this."
Stage 5: The Cycle Continues
If you survive, if you grind through and level up, there's a subtle temptation: to do unto others what was done unto you. "I suffered through this hazing. Why shouldn't they?"
And the cycle perpetuates.
Research confirms this: the endemic rot of shame is perpetuated throughout the industry, and it's so commonplace that it's essentially completely normalized.
Across software development, shame and guilt are used as powerful and destructive forces - developers argue and speak condescendingly on social media, Q&As, and other online arenas, holding others to extremely high standards and letting them know when they don't meet them.
This isn't isolated incidents. This is systemic.
Part 5: Let Me Get Really Personal Here
I'm going to tell you something I've never admitted publicly.
Three years ago, I almost quit tech.
Not because I couldn't code. Not because I didn't love building things. But because I was exhausted from constantly feeling like I wasn't good enough.
I was a mid-level developer at the time. I'd shipped features used by thousands of people. I could solve complex problems. I was objectively competent.
But every day felt like walking through a minefield.
Every decision scrutinized. Why did you use a ternary instead of an if-statement? Why didn't you extract that into a function? Why is this variable named like that?
Every question judged. You don't know how useContext works? You've been using React for two years!
Every mistake amplified. Did you just merge to main without rebasing? Jesus Christ, dude.
I developed anxiety around code reviews. My hands would shake hitting "submit." I'd spend hours double-checking obvious stuff because I was terrified of being wrong publicly.
I wasn't coding anymore. I was performing. Every line was theater. Every commit message carefully worded to deflect potential criticism.
The joy was gone.
One night, after a particularly brutal code review where a senior dev called my solution "amateurish," I sat in my car in the parking garage and cried.
I thought: "I have a degree. Years of experience. I've built real products. Why do I feel like a fraud every single day?"
That's when I realized: the problem wasn't me.
The problem was the culture.
And if I felt this way with my privilege—white, male, English as a first language—how much worse was it for women, for people of color, for non-native speakers, for career changers?
Part 6: The Gatekeeping Problem
Let's talk about gatekeeping because it's everywhere and we pretend it's not.
Negative gatekeeping happens when a senior developer blocks your work but doesn't share their knowledge and help you get better at your craft, or leaders push decisions from the top without sharing their vision or hearing your input.
"You're not a real developer if you use..."
- VS Code instead of Vim
- Create React App instead of Vite
- TypeScript instead of "pure JavaScript"
- A framework instead of vanilla code
- AI tools like Copilot, Cursor
- Stack Overflow regularly
- GUI Git clients instead of command line
Here's a revolutionary thought: there are no "real developers." There are just people solving problems with code. The tools don't matter. The gatekeeping is arbitrary.
"You should already know..."
- Every algorithm from CS101
- Every design pattern
- Every bit flag operation
- Every O(n) optimization
- Every Linux command
- Every terminal shortcut
Bullshit. I've been coding for a decade and I still Google "how to reverse an array in JavaScript." Knowledge isn't memorization. It's knowing where to find answers and how to apply them.
"If you can't [arbitrary skill], you're not ready for..."
- If you can't whiteboard an algorithm, you're not ready to be hired
- If you can't answer this brain teaser, you lack problem-solving skills
- If you haven't built your own framework, you don't understand frameworks
- If you haven't read [specific book], you're not a serious developer
The passive gatekeeping thought of "Isn't it very obvious, I doubt it's worth writing" has the potential to kill any motivation to learn or teach.
These are artificial barriers designed to exclude, not evaluate.
Part 7: The Cost of This Culture
Let me spell out what we're losing:
1. Talented people who could've been great developers quit before they start.
Because the learning curve is steep enough without dealing with assholes every step of the way. How many brilliant problem-solvers walked away because their first Stack Overflow question got mocked?
2. Diversity tanks.
This culture is genuinely believed to be one of the key reasons the industry has trouble attracting women and minority groups to the field - people who are already nervous and perhaps feeling vulnerable putting themselves out there can be put off the industry for good.
When your culture rewards aggressive debate and punishes questions, you're selecting for a specific personality type. And surprise: it's not diverse.
3. Innovation stagnates.
People don't take risks when they're afraid of being wrong. They copy "proven" solutions. They follow trends. They don't experiment.
Fear kills creativity.
4. Mental health collapses.
Anxiety. Depression. Imposter syndrome. Burnout. These aren't individual failings. They're symptoms of a toxic environment.
5. The actual quality of software suffers.
Because when people are scared to ask questions, they write code they don't fully understand. When they're afraid to admit mistakes, bugs get hidden instead of fixed. When code reviews are hostile, people avoid them entirely.
Shame makes people scared to make mistakes and take risks, and they will not innovate.
The irony? In trying to "maintain standards," we're making worse software.
Part 8: "But We Need Standards!"
I can hear the pushback already.
"So we should just accept bad code?" "What about quality?" "Are you saying we can't give feedback?"
No. That's not what I'm saying. Listen carefully:
There's a difference between having standards and being cruel.
High-Quality Feedback:
"Hey, I noticed you're directly manipulating the DOM here. That can lead to state inconsistencies. Want to explore using React state instead? I can pair with you if that helps."
Toxic Feedback:
"Why are you touching the DOM directly? This is React 101. Did you even do the tutorial?"
See the difference?
One teaches. One shames.
One offers help. One offers judgment.
One assumes good intent. One assumes incompetence.
You can have high standards AND be kind.
You can point out issues AND assume the person is doing their best.
You can teach someone a better way AND acknowledge what they did right.
These aren't mutually exclusive. But we've convinced ourselves they are.
"I'm just being honest." No, you're being an asshole. Honesty without compassion is cruelty.
"They need to develop thick skin." Why? Why should surviving emotional abuse be a job requirement?
"This is just how tech is." Then let's change how tech is.
Part 9: My Breaking Point (The Story That Changed Me)
I need to tell you about Marcus.
Marcus was a career changer. Thirty-eight years old. Former teacher. Went to a bootcamp. Got his first junior dev job on my team.
He was hungry. Stayed late. Asked great questions. His first few PRs were rough, but I could see the potential.
One day, he submitted a feature. It worked. Tests passed. But the code was messy—lots of nested ifs, repetitive logic, poor naming.
Our tech lead, a brilliant but abrasive guy, ripped into it:
"This is the worst code I've seen in months. Did you learn to code from YouTube tutorials? This is embarrassing. Reject."
No suggestions. No guidance. Just judgment.
Marcus went quiet in Slack. I DMed him: "Hey, you okay?"
His response: "I think I made a mistake. I'm 38. I don't belong here."
My heart broke.
I called him. We talked for an hour. He told me about his kids. About leaving a stable teaching career. About his wife working extra shifts so he could take the bootcamp. About the months of rejection before he got this job.
"I just want to build things," he said. "I thought if I worked hard enough, learned enough, it would be okay. But I'll never be as good as the people who started at twenty."
That gutted me.
Because Marcus wasn't failing because he lacked talent. He was failing because our culture was toxic, and nobody had his back.
I stayed up that night refactoring his code. Not to fix it for him—but to understand what he was trying to do. And you know what? His approach, while messy, solved the problem in a way none of us had thought of.
The next day, I sat with him. We went through it together. I showed him patterns that could clean it up. I explained why certain structures help. I paired with him to refactor.
His eyes lit up. "Oh! That makes so much sense. Why didn't anyone teach me this?"
That question haunted me: Why didn't anyone teach him?
Marcus is still in tech. Four years later, he's a solid mid-level developer. He mentors juniors now. He's the kindest code reviewer I know.
But how many other Marcuses quit because they didn't have someone in their corner?
Part 10: How We Fix This (No Bullshit Action Items)
Enough complaining. Let's talk solutions. Real ones.
If You're a Senior Developer:
1. Remember when you were junior.
You Googled everything. You asked dumb questions. You wrote terrible code. Someone helped you. Return the favor.
2. Make "I don't know" acceptable.
When juniors ask questions, sometimes say "Good question, let's figure it out together" even when you do know. It models that not knowing is okay.
3. Praise in public, critique in private.
Code reviews are public. If you're going to nitpick someone's code, do it in a DM with context and empathy.
4. Give a shit about the person, not just the code.
Before you comment, ask yourself: "Will this make them a better developer, or will this make them want to quit?"
5. Your experience is not universal.
Not everyone had a CS degree. Not everyone started coding at twelve. Your path is not the only valid path.
If You're a Company Leader:
1. Make kindness non-negotiable.
Brilliant assholes are not worth it. I don't care how good their code is. If they're making people cry, they need to go.
2. Evaluate reviews the way you evaluate code.
Are your senior devs giving constructive feedback? Or are they gatekeeping? Hold them accountable.
3. Create mentorship programs that actually work.
Pair juniors with seniors. Give seniors time to teach. Recognize teaching as valuable work.
4. Normalize asking for help.
Make it a key metric. "How many questions did people feel safe asking this month?"
5. Build psychological safety.
Make it clear: mistakes are learning opportunities, not fireable offenses.
If You're a Junior Developer:
1. You're not the problem.
If you're struggling, if you feel stupid, if you're scared to ask questions—that's not your failing. That's the culture's failing.
2. Find your people.
There are kind communities out there. Discord servers where people actually help. Streamers who encourage questions. Find them.
3. Ask questions anyway.
Even if you get a shitty response, ask. For every jerk, there's someone kind who will help. And the jerks? They'll age out or burn out.
4. Remember who was kind to you.
When you level up, be that person for someone else.
5. Your worth isn't your code.
You are more than your GitHub contributions. More than your LeetCode streak. More than your ability to invert a binary tree.
If You're Anyone in Tech:
1. Call out toxicity when you see it.
"Hey, that comment seems harsh. Can we rephrase?" is powerful. Be an ally.
2. Celebrate learning, not just knowing.
"I learned something new today" should be celebrated more than "I knew this already."
3. Share your struggles.
Talk about the times you failed. The bugs that took you days. The concepts you don't understand. Normalize imperfection.
4. Build instead of tear down.
When you see someone learning, encourage them. When you see someone struggling, help them. When you see someone succeed, celebrate them.
5. Choose kindness.
Every interaction is a choice. You can be right and cruel, or you can be right and kind. Choose kind.
Part 11: What Changed for Me
Here's what I did after my breaking point with Marcus:
I started a mentorship program at my company. Every junior gets paired with a senior. Not for code review—for career support. "How's it going?" check-ins. Safe space to ask "stupid" questions.
I changed how I do code reviews. I start every review with something positive. "I like how you handled error cases here." Then suggestions. Always framed as options, not mandates.
I talk openly about my struggles. I tell my team when I'm stuck. When I Google basic stuff. When I don't understand something. It gives them permission to be human too.
I call out toxic behavior. When someone's harsh in a review, I DM them: "Hey, that came across rough. Want to rephrase?" Sometimes they didn't even realize.
I celebrate questions. In standups, I literally say "Great question" even when it's basic. Because every question someone asks is a question someone else had but was too scared to voice.
I reject the idea that suffering builds character. No. Suffering builds trauma. Support builds character.
My team's changed. People ask questions now. Code reviews are constructive, not combative. Juniors stick around instead of burning out.
The culture shift is real. And it's not because I'm special. It's because I decided to stop being complicit.
Part 12: An Open Letter to Tech
Dear Tech Community,
We're brilliant. We've built incredible things. We've changed the world.
But we're also cruel. And that cruelty is killing us from the inside.
We're losing talented people who could've been great. We're burning out the people who stay. We're building products that lack empathy because we lack empathy for each other.
And for what? To protect our egos? To maintain artificial scarcity? To prove we're smarter?
It's not worth it.
According to Dr. Brené Brown, shame cannot survive when doused with vulnerability and empathy. When we're willing to be vulnerable, open, honest, and caring, we reverse the effects of shame and allow for deeper human connections.
I'm tired of pretending toxic behavior is acceptable. I'm tired of "brilliant jerks" being tolerated. I'm tired of gatekeeping disguised as "maintaining standards."
We can be better than this.
We can have high standards AND be kind.
We can push each other to grow AND be supportive.
We can build world-class products AND treat each other like humans.
The choice is ours. Every code review. Every Slack message. Every Twitter reply. Every interaction.
Choose kindness. Choose empathy. Choose humanity.
Or don't. And watch the best people in our industry burn out and leave.
I know which future I'm choosing.
What about you?
Conclusion: The Developer I Want to Be
I don't want to be the developer who makes people feel small.
I don't want to be the senior who's too important to answer "basic" questions.
I don't want to be the reviewer who's more concerned with being right than being helpful.
I want to be the developer who remembers what it's like to struggle. Who remembers the people who helped me. Who pays that kindness forward.
I want to build a culture where asking for help is strength, not weakness. Where mistakes are learning opportunities, not scarlet letters. Where "I don't know" is the start of growth, not admission of failure.
I want tech to be a place where talented people from any background can thrive. Where your code matters more than your pedigree. Where your potential matters more than your current knowledge.
This isn't idealistic bullshit. It's survival.
Because the current culture is unsustainable. We're burning through people. The turnover, the burnout, the trauma—it's all preventable.
We just have to give a shit about each other.
One Last Thing
If you made it this far, thank you.
If this resonated with you, please share it. Not for me—for the junior developer who thinks they're not good enough. For the career changer questioning their decision. For the senior developer who's tired of pretending toxicity is normal.
We can change this culture. One kind code review at a time. One answered question at a time. One "you belong here" at a time.
Let's build software. And let's build each other up while we do it.
No more shame. No more gatekeeping. No more cruelty disguised as standards.
Just honest, compassionate, human developers building things together.
That's the industry I want. Let's make it happen.
Connect With Me
I'm Elvis Sautet (@elvisautet), and I'm trying to build a kinder corner of tech. If you're tired of the toxicity too, let's connect.
Share your stories. Your struggles. Your tech path. Snippets of code. Hacks. Your moments of kindness. Let's normalize compassion in code.
Because the future of tech isn't about who's the smartest. It's about who we lift up along the way.
P.S. If you're that junior developer reading this at 2 AM, feeling like you don't belong: You do. Keep going. It gets better. And when it does, be the kind person you needed.
Top comments (1)
Thank you so much for sharing! As an engineer with 5 years of experience, I've dealt with my fair share of toxicity.