I am Lino
June 3, 2026

"Senior": the title you earn by surviving, not by standing out

Posted on June 3, 2026  •  8 minutes  • 1577 words
Table of contents

A friend who works at a consultancy has spent five years wondering when they’ll finally make him “senior.” His desk neighbor has been one for two years, even though he’s shown up late four times this week, keeps making the same mistakes as always, and whose most memorable technical contribution was changing the IDE color theme. The difference between them: the colleague hasn’t left. Yet.

Open any job listing in the tech industry and you’ll find they’re looking for senior developers. Thousands of them. Always. It’s the most in-demand profile, the most sought-after, the one that shows up most often in LinkedIn headlines alongside buzzwords like “go-to resource,” “technical leadership,” and “systemic thinking.”

And then you join the company and meet the in-house seniors.

This is where the textbook definition and operational reality have an awkward hug and stare at each other, not sure what to say.

What the handbook says vs. what actually happens

The official definition of a senior developer is generous and sensible: someone with solid technical judgment, capable of making architectural decisions, mentoring junior developers , communicating with the business side, and understanding the system as a whole.

Sounds good. That’s what it should be. And in some teams — the minority — that’s exactly what it is.

But there’s another type of senior that’s far more common in the wild habitat of the Spanish tech company. This specimen isn’t set apart by their architectural judgment or their ability to mentor. They’re set apart by a far rarer and, in certain contexts, surprisingly valuable trait: they’ve been here a long time and still haven’t left (what a senior developer really is ).

They know the production system because nobody else has touched it in four years. They know why the database table has that cryptically named column because they created it in 2021 and never documented it. They remember the meeting where someone decided to use that framework everyone now despises. They are, in essence, a human hard drive with a mild case of Stockholm syndrome (Senior Developers Leaving Tech in Droves ).

The most honest promotion process nobody ever writes down

In many companies, the path to senior goes something like this — even though nobody writes it down anywhere:

Years 1 and 2: You’re a junior. You ask a lot of questions, you mess up, you learn. That’s fine — it’s the deal.

Year 3: You start knowing the system. You also start knowing its dirty laundry: the technical debt, the broken processes, the decisions that make zero technical sense but “it’s just how we’ve always done it.” This is the critical fork in the road.

The fork: Some developers, at this point, leave. They take what they’ve learned, find somewhere else, and keep growing. Those who stay — for whatever reason, all of them valid — enter the category of “institutional knowledge.”

Year 4 and beyond: You’re a senior now. Not because what you do has fundamentally changed, but because you’re the only one who remembers why the payments module works the way it does, and that, in the absence of documentation, carries enormous internal market value .

The senior as life support system for other people’s chaos

In these companies, a very specific dynamic takes hold — one that deserves to be called by its name: the senior absorbs everything the system fails to handle.

No onboarding? The senior runs an informal orientation for every new hire. No documentation? The senior answers questions. Does the planning process keep producing impossible projects? The senior swallows the overtime to make the numbers work. Has nobody made a coherent architectural decision in years? The senior patches things.

And here’s the part nobody says in the performance review: that senior isn’t being recognized for their technical talent. They’re being exploited for their tolerance for chaos .

Those aren’t the same thing. And the difference matters: one makes you grow, the other grinds you down.

34% of developers with more than 15 years of experience say they’re planning to leave the industry entirely within the next two years, and the reasons they give don’t include “the work is too hard.” What you do see, consistently: “I’ve been fighting the same battles for years,” “leadership doesn’t understand engineering,” and “pressure to ship features instead of building sustainable systems.”

Bottom line: they’re not leaving because they can’t hack it. They’re leaving because they’re fed up.

The indispensability trap

There’s a particularly twisted mechanism used by certain companies you’d want to avoid: turning indispensability into a trap dressed up as recognition.

“You’re the only one who knows this system” sounds like a compliment. In reality it’s a description of a serious organizational failure: critical knowledge lives in one person’s head and nowhere accessible. But instead of fixing the problem — documenting things, transferring knowledge, building processes — many companies just hold onto the knowledge carrier .

And the knowledge carrier, who’s no fool, figures out that their value comes not from growing but from staying. Which creates a perverse incentive: the less you document, the messier the system you control, the more indispensable you are. It’s basically a business model.

The problem is that path has a very low ceiling. And a very high personal cost.

The junior who doesn’t know their senior is broken

There’s a piece of collateral damage here that rarely gets mentioned: the effect on the team’s junior developers.

The junior joins with energy, enthusiasm, and a romantic idea of what it means to grow in this profession. They look to the senior — their default role model — and see someone who solves problems with patches and accumulated experience, with no time to explain the reasoning behind them; who runs on intuition rather than explicit judgment, because the judgment was never written down; who tolerates situations an outside observer would call unacceptable with a resignation that looks a lot like professionalism; and who carries the system’s institutional knowledge in their head like some kind of biblical curse.

And the junior learns. Learns that this is how things work around here. That endurance is a virtue. That knowledge isn’t shared — it’s hoarded. That experience means surviving, not growing .

And so the cycle perpetuates itself with remarkable efficiency.

What an actual senior looks like (spoiler: they still exist)

To be fair: the other kind of senior does exist. The one who actually matches the handbook definition. The one who, after years of real work, has developed something you can’t fake or buy: judgment .

Judgment to know which technical battles are worth fighting and which ones aren’t. To read a business requirement and anticipate where the problem nobody’s spotted yet is hiding. To review a PR not just hunting for bugs, but asking whether the solution still makes sense six months from now. To tell a product manager, politely but without flinching, that what they’re asking for can’t be done right in two weeks .

That profile exists. And it’s extraordinarily valuable. And in many companies, they’re lumped in with the seniority-by-tenure senior in the same salary band, the same job title, the same job posting. Which is, at the very least, imprecise.

What to do if you’re the one holding it all together

If you’ve recognized yourself somewhere in this article, there’s a question worth asking yourself honestly: are you growing, or are you just holding on?

Those aren’t the same thing. Growth hurts, but it leaves something behind. Holding on hurts too, but it only leaves burnout .

If the answer makes you uncomfortable, good. Uncomfortable answers are the ones that get things moving.

And if you decide to leave, don’t feel guilty about the knowledge you take with you. Nobody invested in documenting it. That’s the company’s call, not yours.

Next time a job ad asks for a “proactive senior who loves working in a team,” ask in the interview how many seniors they have and how long they’ve been there. The answer will tell you whether they’re looking for technical judgment or someone willing to put up with what everyone else refused to. Those are very different things — even if the contract calls them the same thing.

Sources and references

Because if you’re going to survive five years in production without documenting anything, at least someone out there wrote about it.

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.