There is also the scenario where the “senior developer” just outlasted everyone else. They started when the company was small, didn’t really know what they were doing then but because they have built relationships with the right people and no where all of the bodies were buried - because they buried many of them - have an outsized influence on the organization, whether they are good or not.
Then you have two things happen. All of the talented people leave and you have the Dead Sea effect and the “senior developer” is nothing more than an expert beginner.
Personally, my favorite book about old coders is Coders At Work (https://www.amazon.com/Coders-Work-Reflections-Craft-Program...). It's a bunch of interviews with programmers who have created programming languages and lots of the fundamental software we all rely on. It showed me what the journey to being a great programmer can look like.
To me, senior is a corporate term. Great programmers build great things. Senior developers get promoted. I sometimes ask young programmers this: Do you care about the craft or the career? I think being a great programmer will make a person money. There aren't that many truly great programmers. But if they're impatient or they don't think they can be great, they can probably be senior.
Becoming senior is easy: Just help your boss accomplish their goals. Pay attention and develop skills that will help you do this no matter where you are and what you're working on. If you over-specialize in a specific organization or person's need, you become the expert beginner and you can't leave or you will struggle.
Some of the things that help a person be senior can also make them great. But the path to being great is a very different and personal one (at least that's the impression I got from Coders At Work. I make no claims for myself.) Jeff Dean is undoubtedly a great programmer and was also the most senior developer at Google for a long time. They made new levels just for him. So they can overlap. If someone is lucky and their job is great, the things that make them senior can also make them great. If their job sucks and management is terrible, they'll have to choose every day between doing something great or doing something to get promoted (being senior.)
My favorite article on the journey of a software engineer is this one: https://medium.com/@webseanhickey/the-evolution-of-a-softwar... . To me it's the story of someone who started off trying to be senior but then started to become great.
I would say both. But the field is littered with idealistic developers who “care about their craft” while their employers care only about profit and then are surprised when years later they discover that they have been taken advantage of and underpaid.
I agree? Those are definitely necessary areas to master, but someone can achieve that without really being senior.
What I think makes someone actual senior is how they deal with failure. Anyone can show up and handle a task when they know how to do it and execute it correctly. When things go wrong is when seniority is important. Someone who has failed and watched others fail, seen servers go down, fixed critical bugs in production, made terrible estimates, over promised and underdelivered will have the thick skin you need. Failing and watching others fail is invaluable experience and cannot be taught in schools/bootcamps. Approaching failures unemotionally, moving immediately to what the next steps need to be is a big part of what makes someone senior to me.
Mistakes, rewrites, late nights, firefights, and deadlines.
Core dumps, memory leaks, hardware faults, and plain bad luck.
Big O, data flow, always learning -- or out you go.
Manager metrics, schedules hectic, methodology hegelian dialectic.
Taking the heat, feature creep, open office, uncomfortable seat.
Holy wars, revolving doors, carpal tunnel, all you can take? There's always more.
Fucking suits, random reboots, and the ever present "thousand language stare".
Oh yeah, pressure -- lots of pressure. And time, time, time.
Metric shitloads of time.
Time, man. You gotta do your fucking time.
All of these qualities would be expected of any person, who is more experienced than some other people, in any field. An experienced foreman is more independent than a day labourer.
What about something like: "A senior developer is more able to reason about interactions between separate, but related systems." Or: "A senior developer is more able to dig into the lower level bytecode of a Java application to debug a performance issue."
While my examples might not be perfect, at least they make an attempt of being much more concrete.
The problem with this article is that it's describing the world as it should be and not as it is. What it's telling you is wrong.
In my experience, becoming "senior" has nothing to do with anything other than leverage. There is no internal logic, no objectivity, no consistency. There is no SAT of programming skill. There is no way to quantify that can't be gamed.
And even if there WERE an objective measure of programming skill, promotions have very little to do with skill. In my experience managers have a "goal ratio" in mind of senior/junior and try to keep the company at this ratio. They won't promote 3 people at once for example (yet no article ever says this?).
The pretense of truth isn't just a a distraction; for a large enough group of people with a great number of articles, it's a fog. It prevents all but the eagle-eyed or the timely from penetrating it to discover truth.
The first chart is difficult to understand because it flips the curve to preserve the parallelism between "less" and "more"... which the last chart forgoes anyway.
Also: why an "arc" as opposed to another kind of curve?
Also this 20 person survey is hardly scientific, so you could probably come up with lots of interesting, alternative ways to display the data. I'm sure there were some compromises made to stay readable and concise.
But the curves are basically the opposite of this. They show less horizontal movement at the junior level than the senior level. The "peak X" you are looking at is not what it appears, you are seeing a "peak seniority" level on each graph and the "skill gain" or whatever is accelerating towards infinity as you approach the most senior person (which you can never reach...?)
Here's my shot-in-the-dark, random attempt to line up the curves more to my intuitions and make them kind of work in relation to each other:
Since there's no quantification defined for either “seniority” or the things measures against it, the shape of the curves is meaningless, anyway.
Two pieces of feedback
- What is classified as influence is not all or nothing. In my mind it is covering multiple distinct traits
- The quote "At your company, it’s important to understand which arc is valued by your team and managment." screams bad manager to me. A good team builder will balance teams with these strengths according to the proportion that the tasks demand.