Arcs of Seniority(stevanpopovic.com)
stevanpopovic.com
Arcs of Seniority
https://www.stevanpopovic.com/arcs-of-seniority/
32 comments
I'll second that resilience is one of the most useful traits, especially if it's honed from experience.
[deleted]
Meh, I'm trying to decide if articles like this are just irrelevant or are actively bad.
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 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?).
Why is time on the y-axis for all of these examples? Is that a (perverse) convention even outside of econ somewhere?
It's not really time. Seniority here is more of a quality than it is just something determined purely by time. So "Senior Software Developers" are those with some of the correlated skills in the article.
Ok, but seniority is still the independent variable in all those graphs, so it belongs on the x-axis.
No, seniority is the dependent variable. The other factors determine seniority, not vice versa.
The article uses phrases like "As a developer become more senior, they become more independent.", which indicates they view seniority as the independent variable.
Yeah, it looks like seniority is the dependent variable. It also looks like it's the monotonically increasing variable. Seems like it should be on the X axis.
Time isn't on any axis. The y axis is seniority.
https://www.stevanpopovic.com/static/e1db44c18f06c967873e3d4...
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?
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?
The arcs seem to make a lot of sense actually, if you consider the law of diminishing returns. One would approach peak X as you become more senior, but you would accelerate toward peak X more quickly at first, since you're new and learning. The difference between knowing your first thing and the 2nd is 100%, while you're 101th thing learned only nets you a 1% gain.
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.
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.
>One would approach peak X as you become more senior, but you would accelerate toward peak X more quickly at first
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...?)
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...?)
Ah true. Got it backwards. Graphs should be concave. In any case, can one ever reach perfection?
Yeah the article makes no attempt to explain why they are "curves," or why the slopes look like that at all.
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: https://sketch.io/render/sk-6839906b1c270084fb96acb3fdae4249...
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: https://sketch.io/render/sk-6839906b1c270084fb96acb3fdae4249...
> Yeah the article makes no attempt to explain why they are "curves," or why the slopes look like that at all.
Since there's no quantification defined for either “seniority” or the things measures against it, the shape of the curves is meaningless, anyway.
Since there's no quantification defined for either “seniority” or the things measures against it, the shape of the curves is meaningless, anyway.
I enjoyed this counterpoint to “don’t call yourself a programmer”, which TFA links to in a footnote. http://yosefk.com/blog/do-call-yourself-a-programmer-and-oth...
For me, this article doesn't seem to provide much insight at all.
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.
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.
Very nicely done
Overall, very good. I might share this to help people out.
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.
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.
I wish this were always true.
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.
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
https://daedtech.com/how-developers-stop-learning-rise-of-th...
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.
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
https://daedtech.com/how-developers-stop-learning-rise-of-th...
Yes. The article is a bit tautological. It's not defining seniority in terms of time spent. He actually says this at the end. Instead he's defining a "senior developer" as someone who has a necessary mix of the qualities he talks about. It would be more accurate to say "These are the traits your manager will tell you to develop to get promoted."
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.
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.
Do you care about the craft or the career?
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 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 think the article isn't so much talking about job titles. So, talking about senior instead of "senior" ;-)
The article is likely the exception, where people do grow and become better at grasping the depth and essence of the problems their solving and the breadth too. I’ve never seen people grow like that outside of elite companies, and even at that it’s rare.
If you have juniors, then you are a senior.
Not necessarily. If you too are a junior, and you're in charge of them, it could mean you have a problem. If you know what areas you don't know and your learning-how-to-learn skills are good, you can still be fine if you find folks to help you. But there's still a high risk to make a mess.
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.
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.