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 (13)
Hahahaha yes 😭 I was exactly that mid-level developer once.
I still remember working on an Angular app right around the time React was becoming super popular, and I genuinely started thinking: “What if we just rewrote everything?” 💀
At some point I even found one of those Angular-React integration libraries so we could use React inside Angular. Absolute peak “I watched a conference talk and now I have opinions” energy xDDDDD
Thankfully, actual senior engineers were around to protect the codebase from my revolutionary ideas 😅
That's artisanal mid-level energy right there 💀. You weren't satisfied with a rewrite — you wanted a hybrid rewrite. Peak "I read the headlines of two blog posts and connected them with confidence."
I'm not a fan of labelling a person. There is too much knowledge to give a person a level sector wide. We are all AI juniors because the mainstream use is only a few years old and it still changes in important ways.
I do connect with the knowing enough to be dangerous mentality. I think it is a trap we all fall in from time to time. This has nothing to do with your overall knowledge. I think it is just our brain that wants to use the information that has just been put in front of us.
This is why experimentation is so important. You can act on that desire and have real world experience.
This is the biggest problem when giving people AI. Now people can act on that impulse of doing a rewrite, and it will be quick. The problem is that LLM's are trained on yesterdays code, which means to fill the gaps it will do weird stuff you only discover later on.
If one thing fits the mid-level developer as being portrait in this post, it is AI.
Yeah, I think you're right—the label is a shorthand for a mode more than a person. We've all been "mid" on some random Tuesday about some random thing we just learned.
And the AI point is brutal. It makes the dangerous part faster without fixing the "what breaks later" part. Giving someone a faster way to be confidently wrong is... not the upgrade we think it is.
I think part of the mid-level anxiety today comes from the feeling that the ground keeps moving under them.
Juniors are still learning fundamentals, so experimentation feels exciting.
Mid-level developers are in the weirdest position:
they finally became productive enough to feel valuable, right when AI started automating parts of the work they spent years learning.
Oof, yeah. That's the part I didn't name explicitly but you're right. Mids get hit hardest by the AI thing too — juniors are learning with it, seniors have pattern recognition to filter it, but mids are supposed to be the "productive ones" while also competing with autocomplete. Weird spot to be in.
The junior pointing out that the docs are outdated is doing something genuinely valuable — not because of the insight itself, but because they haven't normalized the dysfunction yet. Every experienced engineer on the team walked past those stale docs a hundred times and stopped seeing them. The junior sees them because they needed them and they didn't work.
The mid-level 3am refactor pattern comes from a real place: they've identified something genuinely wrong and have enough skill to fix it but not enough context to know why it was done that way or what breaks when it changes. The missing ingredient isn't ambition — it's the "let's think about what breaks in six months" reflex that only comes from having been the one who changed something that broke in six months. You can't shortcut that by telling people to be more careful. You build it by giving them scope and letting them own the consequences.
Yeah, you said this better than I did. The junior thing isn't about insight — it's about need. The docs didn't work for them, so they noticed. The rest of us just learned to swim around the broken stuff.
And totally agree on mids. You can't teach the "what breaks in six months" reflex in a Slack message. You have to let them break something small-ish and sit with the aftermath. That's the part that actually sticks.
The best devs eventually realize that shipping stable, understandable code beats winning architecture debates. Juniors ask because they’re learning, mids push because they’re proving, seniors pause because they’ve already survived the consequences.
Yep. "Pause" is the right verb. The whole job starts looking different when you realize the goal isn't being right — it's not getting a call at 2am.
Juniors ask. Mids assert. Seniors pause. I might steal that.
I'm that mid dev 😅
We all were. The ones who say they weren't are either lying or about to do something unhinged next week 😅
Welcome to the other side.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.