Here's a thing nobody talks about in the "building a healthy engineering culture" TED talks: junior developers are not the problem. They're predictable. They ask questions. They listen. They know what they don't know, which is half the battle.
The mid-level developer? Now there's your chaos agent.
The Tier List (Controversial, I Know)
Juniors: "I don't understand this. Can you explain it?" Translation: easy, good faith problem. You explain it. They learn. Maybe they code it a weird way, but at least they'll tell you before shipping. These people are trying not to sink the boat.
Mids: "Yeah, I read a Medium article about this architecture pattern once." Translation: oh no. They now know juuuust enough to be confident, not enough to see all the edges they're missing. They're about to refactor your entire codebase because TypeScript stricter settings are "table stakes for any serious project" (they read an article).
Seniors: "We could do it that way, but let's think about what breaks in six months." Translation: calm, because we've seen it break in six months before.
Why Juniors Are Actually Great
A junior asked why the onboarding docs were three years out of date. We laughed. Then realized: none of us had updated them because we all just knew how things worked now. New person had to learn from Slack messages and asking people questions. We'd optimized ourselves into a bottleneck.
Here's the thing about juniors: they haven't been beaten down yet. They still think documentation should exist. They still think things should be findable. Revolutionary concepts, I know.
You point them at a task, they get stuck, they ask where the docs are, and you realize there aren't any. Or they're scattered across four different Slack threads from 2021. They don't know yet that this is normal. They think "onboarding" means something other than "asking random people questions until you figure it out."
The risk with a junior is they'll point out all the gaps and make you feel bad about it. The upside is they're collaborative about fixing it. They're not trying to prove anything. They're just trying to do the job and not feel lost the whole time.
The Mid-Dev Energy Crisis
Mids are where things get spicy.
They've shipped something. Maybe it worked, maybe it kind of worked, maybe it caught fire but they're not thinking about that right now. The point is: they have success weight. They're no longer a question mark—they're a contributor with opinions.
But here's where it gets fun. They've read enough to be dangerous, not enough to be wise.
The Mid-Dev's Greatest Hits:
- The Architecture Reorganization: "I've been thinking... what if we moved everything to microservices? Distributed systems are the future. I watched a talk." No strategic reason. No pain point being solved. They just watched a talk.
- The Framework Rewrite: "Okay but what if we rewrote the whole thing in [new framework]?" Why? "Better DX." Whose DX? Their DX for writing new code while everyone else owns production incidents.
- The Premature Abstraction: Four months into the project, they've created a custom hook ecosystem so complex that only they understand it. Junior tries to use it, asks for help, gets a 40-minute explanation of prop-drilling alternatives nobody asked for.
- The Aggressive Code Review: They're reviewing a junior's PR. The code works. It's readable. It passes tests. They leave 12 comments asking why the developer "didn't consider using a custom hook" or "didn't memoize aggressively" or "didn't think about server rendering" even though it's a form in an admin panel that hits 30 users a month.
The mid-dev is learning that they can have opinions, and they're exercising that power like they just got access to a 2002 Honda Civic and need to test the engine.
Why This Happens (And It's Not Their Fault)
Here's the uncomfortable truth: mids are in the danger zone of confidence versus competence. They're past the "I don't know anything" phase but not yet in the "I know what I don't know" phase.
The Dunning-Kruger effect is real, but it's not really about stupidity. It's about scale. A junior's worked on one thing. A mid's worked on three to five things. That feels like a lot. It feels like they've seen the patterns.
Until they haven't. Until they learn (the hard way) that "best practice" depends on context. That premature optimization isn't just bad—it's actively hostile to shipping. That code that's boring and works beats code that's clever and breaks at 2 AM.
The thing is, every senior developer alive was a mid once. Most of us pushed something completely unnecessary to production while congratulating ourselves on our architecture skills. Most of us spent a week optimizing something that didn't matter. That's not a failure—that's training.
What Actually Works
If you're a senior managing a mid:
Don't tell them they're wrong—that just makes them defensive. Instead, ask them questions:
- "What would break if we do this?" (Often: silence, then they realize something.)
- "How long will the refactor take? What's the payoff?" (This makes them do math. Math is humbling.)
- "Can we ship the simple version first and refactor if we hit actual problems?" (This teaches patience.)
Give them ownership of something that can break a little bit without destroying the business. Let them experience consequences without trauma. This is how you turn a mid into a senior.
If you're a mid reading this:
Look, you're doing great. You're learning fast, you're getting stronger, you're building real things. The fact that you're in this uncomfortable middle zone means you're growing. That's good.
But here's the move: start asking seniors why instead of telling juniors what. When you're about to suggest a rewrite, ask a senior if they've seen that problem before. When you're reviewing code, ask yourself if you're protecting the system or protecting your ego.
The seniors you respect aren't the ones with the cleverest solutions. They're the ones who know when simple is better. You can get there faster than you think, but only if you stay curious instead of confident.
The Real Insight
Juniors are dangerous in ways we expect—they might not write optimal code, they might miss edge cases. We've built systems to catch that (code review, testing, etc). We expect juniors to be junior.
Mids are dangerous in ways we don't expect. They're good enough that we trust their judgment. They're confident enough that they don't ask for second opinions. And they've read just enough Medium articles to be genuinely convinced they're right.
The thing that separates a mid from a senior isn't skill—it's humility. It's knowing that "I don't know" doesn't mean you're not good at this; it means you're paying attention.
So yeah, keep your juniors close. Let them ask questions. Appreciate that they still think code should be boring and work-y instead of clever and break-y.
And the mids? Keep them curious. Give them hard problems. Have them explain their solutions to someone who wasn't part of the decision. Let them fail small.
The goal is to make juniors into mids and mids into people who remember what it felt like to be certain about everything.
Top comments (0)