Skip to content
Domain Specific Language

The myth of the Senior Developer

I have been thinking lately about what Senior Developers (Senior Engineers, Software Architects, etc.) contribute to an organization.

There is a long list of attributes a senior developer can have, two of them are—

I want to examine this dogma, and perhaps shine a light of self-criticism on it.

I spent almost ten years at a large mobile phone company, and somewhere along the line someone, if I may self-deprecate for a while, mistook confidence for competence.

Staying in one place a long time let me absorb a lot of different competences and that, perhaps, is one definition of seniority. To know a lot of different things. Seniority is perhaps also the willingness to stop and help others, and hopefully there is something that is being contributed. If nothing else, a little human warmth may have been exchanged.

But I want to self-loathe.

What are the nefarious, dirty things, that keep seniors climbing on top of juniors—boots in their faces, grasping upwards but constantly falling short?

The senior edge

At my current job I have colleagues of varying seniority. Some of us have been working together for five years, taking this company from startup status with one customer, to having hundreds of customers.

I have been working with large parts of our codebase since it was just a little puppy, a few lines long. Now the code is full-grown and spans a few hundred thousand lines of code.

I am intimate with half, or at least one third of all the code. It is very hard for someone completely new to get a high level overview. Every new task is an overwhelming campaign into the unknown. I have a very good understanding of everything from small details up to the overall architecture. The juniors are spending their time reading completely new code every time they get a new task.

I can probably spend hours talking about a single application and even then I probably wouldn't touch on all the quirks, good design choices, bad design choices, or the ever growing list of issues.

It's easy to be creative when I'm not spending most of my time trying to understand what the code I'm looking at is doing. I already know, so I can just skip straight into my creative mode and start adding to an ever expanding advantage.

It's easy to be senior because I know most of the things already. It's easy to be senior because I review most of the code on its way in.

That is the senior edge.

The junior perspective

Even if I had the time, and even if I wanted to spend all my time, I would not be able to explain everything. It took me five years to get here, how would I be able to fully transfer that knowledge efficiently?

That's why it's so hard to be the junior.

What about off the cuff comments? Things that I didn't mean as hurtful or demeaning, but definitely came off that way? I know I've said some really dumb things, but not because I remember myself saying them. I'm sure people do remember what I said, though. No it's because I remember what people said to me when I was a junior developer.

Things like—

"How hard can it be?"

People actually say this unironically.

"That's easy"

Not a good look. Someone without my domain knowledge will probably stare into their screen for several hours before asking for help. Why did they waste all that time? Because I said something hurtful.

I don't want it to be that way.

There are no 10x engineers. That myth is already busted. Most probably it's just someone who started early and wrote a lot of code.