I was going to write something technical this week.
Maybe about architecture patterns. Or why most “clean code” debates are just ego in disguise.
...
For further actions, you may consider blocking this person and/or reporting abuse
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.