I was going to write something technical this week.
Maybe about architecture patterns. Or why most “clean code” debates are just ego in disguise.
But instead, I’ve been thinking about Jason.
Jason left 20 days ago.
Not because of layoffs.
Not because of drama.
He left to focus on his own business.
And ever since, the office feels… different.
Not quieter.
Just less sharp.
Jason was one of those rare developers who looked like a senior on paper — years of experience, big projects, scars from production outages — but still thought like a curious junior.
And that combination? It’s dangerous. In a good way.
Because most juniors are hungry but unsure.
Most seniors are confident but tired.
Jason was hungry and confident.
The Thing About “Junior” Titles
We love labels in tech.
Junior.
Mid.
Senior.
Staff.
Principal.
Wizard.
But Jason taught me something simple:
Experience is not about years.
It’s about ownership.
I’ve seen juniors with 2 years of experience take more responsibility than seniors with 10.
I’ve seen seniors hide behind architecture diagrams like they’re ancient scrolls nobody else can read.
Jason never hid.
If something broke, he didn’t say:
“Who wrote this?”
He said:
“Okay. Let’s fix it.”
And then he’d open the logs.
Debugging With Him Felt Different
You know how debugging usually goes:
- Panic.
- Blame the backend.
- Blame the frontend.
- Blame DevOps.
- Restart everything.
- “It works now.”
Jason skipped steps 2–4.
He’d sit down, calm, almost annoyingly calm, and say:
“Let’s reproduce it first.”
No drama. No Slack wars. No ego.
And when a junior dev asked what might have felt like a “stupid question,” he never did the senior sigh.
You know the sigh.
The one that says:
“You should know this already.”
Instead, he’d explain it from first principles. Like he was explaining it to himself.
That’s when I realized something uncomfortable:
The best seniors are just juniors who never stopped asking why.
Career Advice He Never Officially Gave
Jason never did motivational speeches.
He wasn’t the “LinkedIn wisdom thread” type.
But he’d drop small comments that stuck.
Once, after a long sprint, I complained that I felt behind compared to “real senior engineers.”
He said:
“Behind who? The version of you that doesn’t exist yet?”
That one hit harder than any performance review.
We compare our daily messy reality with someone else’s highlight reel.
GitHub stars. Conference talks. Viral posts.
Meanwhile, the real growth happens in:
- fixing that bug nobody wanted
- refactoring code no one notices
- saying “I don’t understand this” in a room full of confident faces
Jason did all three.
The Junior With Senior Energy
Here’s something I’ve noticed:
A lot of juniors try to “act senior.”
They avoid asking questions.
They over-engineer simple tasks.
They use big words in code reviews.
Jason did the opposite.
He’d say:
“This might be a dumb idea, but…”
And then propose the most elegant solution in the room.
Confidence without arrogance.
Experience without ego.
That’s rare.
The Day He Told Me He Was Leaving
It wasn’t dramatic.
No emotional music.
No mysterious calendar invite.
He just said:
“I think it’s time to build something of my own.”
And honestly? I wasn’t surprised.
People like Jason eventually outgrow being “just” employees.
They don’t chase titles.
They chase problems.
Still, when someone like that leaves, you feel it.
Because you lose more than a co-worker.
You lose:
- the person who challenges your thinking
- the calm voice during production chaos
- the silent standard everyone measures themselves against
What This Has To Do With You
If you’re a junior developer reading this:
Stop trying to look senior.
Instead:
- Take ownership of small things.
- Ask better questions.
- Admit what you don’t know.
- Care about the system, not just your ticket.
That’s how you grow.
And if you’re a senior:
Remember how it felt to not understand half the things in the codebase.
Be the person who explains — not the person who sighs.
20 Days Later
The code still runs.
Deployments still happen.
Standups still feel slightly too long.
But sometimes during a bug discussion, there’s a pause where Jason would normally say:
“Wait. What assumption are we making here?”
And nobody says it.
So now I try to.
Maybe that’s the real impact of good engineers.
They don’t just ship features.
They change how you think.
And honestly?
We miss him.
Not just me — the whole team.
We miss the calm during chaos.
We miss the random architecture debates.
We miss the way he’d quietly raise the standard without ever announcing it.
The Slack threads are still there.
His old commits are still in the repo.
But the chair is empty.
Jason, if you’re reading this — we’re proud of you.
We’re cheering for your business.
We know you’re going to build something great.
But yeah… we’re also looking forward to the day we grab coffee again, argue about code, and pretend we’re not secretly debugging life at the same time.
Good teammates are hard to find.
Good friends even harder.
See you soon, brother.
PS - Now I am gonna expand my work inviting new developer - it's part-time.
So If you are based on Europe and America and interested in that, please feel free to contact me anytime.
Top comments (16)
This is emotional blogging masquerading as career advice. Jason's real skill wasn't 'thinking like a junior'—it was incident response discipline. 'Let's reproduce it first' isn't wisdom, it's SRE 101. The dangerous part? You're conflating personality traits (calm, humble) with engineering rigor. I've worked with plenty of 'nice' juniors who still shipped race conditions to prod. The actual lesson buried here: ownership transfers institutional knowledge better than documentation. When Jason left, he took your team's debugging heuristics with him. That's a bus factor problem, not a personality gap. Write runbooks. Record those 'what assumption are we making' sessions. Romanticizing individuals over process is how teams collapse when the 'irreplaceable' person quits.
I really appreciate you calling this out — you’re absolutely right that “let’s reproduce it first” is basically SRE 101 and what Jason consistently showed was strong incident-response discipline, not just personality traits, and I agree that rigor and process always matter more than being “nice.” The bus factor point especially hits home.
I think you’re pointing at something important here.
What looks like a “great engineer” from the outside is often really a pattern of disciplined behaviors that the team hasn’t fully formalized yet. When that person leaves, the behavior disappears because it was never turned into shared infrastructure.
In governance research this sometimes shows up as Authority Drift. Over time the real decision pathways move from documented processes to specific individuals who consistently make good calls under pressure.
The moment that person leaves, the system loses more than a coworker. It loses the operational heuristics that were quietly guiding decisions.
Runbooks, incident reviews, and recorded debugging sessions are ways of converting those behaviors back into shared infrastructure so the system doesn’t depend on one node.
So I agree with your point about process. But I think the interesting question is how teams recognize those behavioral patterns early enough to institutionalize them before they concentrate around one person.
You're absolutely right. The shift from individual expertise to a more distributed, documented system is often overlooked until it's too late. The key challenge is not just recognizing these critical behaviors, but also building the right channels to extract and share the knowledge before it becomes too reliant on a single individual.
Institutionalizing these practices—whether through documentation like runbooks, post-mortem reports, or even mentorship programs—allows teams to evolve without the risk of losing essential knowledge. This can be difficult in fast-paced environments where the focus is on shipping code quickly, but making time for knowledge transfer at every level ensures that the team grows and becomes more resilient in the long run.
The real test for teams is creating a culture where this knowledge-sharing becomes the norm, rather than something that only happens in response to a crisis.
Loved the article, the situational context and this highlights the much needed versions of senior engineers that we actually enjoy working with, infact it highlights maturity. Couldn't agree more to the statement 'Good teammates are hard to find'.
I also worry about a hidden (or sometimes visible) pattern within the technical community, wrote about it here (dev.to/shitij_bhatnagar_b6d1be72/a...) would be useful to get any views / suggestions.
Thank you so much for this — I really appreciate you highlighting the maturity aspect, because technically strong engineers are valuable, but engineers who combine depth with empathy and long-term thinking are the ones who truly elevate a team. I’ll definitely check out your article as well, since these hidden patterns in our technical community often affect architecture decisions, collaboration quality, and even code ownership more than we realize — would love to exchange thoughts on possible solutions.
Nice! Well written - touching, but in a good and non-sentimental way ... yeah, people like Jason are pretty rare, and are to be cherished :-)
Thank you so much — that truly means a lot, and I’m really glad the tone felt balanced. You’re absolutely right, people like Jason are rare, and beyond the human side, having someone with that level of technical depth and quiet reliability on a team is something you don’t fully appreciate until you’ve had to solve hard production issues without them.
Learn a valuable lesson from the post "stay hungry and humble" thanks
Steve jobs said "Stay hungry, Stay foolish"
Didn't know this is how seniors feel about junior, one day I would love to experience that fr
Thanks, friend!😎
Liked it. I want to stay hungry and confident.
Thanks.
Wow, that is a good perspective!!
I am based on United States and hope to work with you.
I will write you via your t.g✌.
I will wait for your response.