Aside from the articles statement that “maybe people who can’t teach shouldn’t do things”; which is easily rebuffed as teaching is an entirely separate skill from doing, great teachers can be terrible do-ers and vice-versa.
Juniors are a problem for the mercenary culture that companies have created by attempting to suppress wages of long term staff.
Namely, a Junior is an investment, you can get a 10/10 senior who knows your company inside and out. A new vanguard, a repository to store tacit, institutional knowledge; but no sufficiently trained junior who is “good enough” to be validated externally is going to stick around for an abysmal salary.
Even if a junior wanted to stick around for his/her mentors; those mentors likely move around often too- and the ones that don’t.. largely can’t due to being poor interviewees.
It’s exceedingly rare these days for people to be loyal to companies for more than 3-4 years.
So why would I as a company: invest 6-12 months of a seniors time when I have so little of it, for the benefit of someone else’s career? They’re just going to leave once trained after all; it’s pretty rare for companies to have a genuinely altruistic mindset- and it’s not cheap labour you’re getting back either.
The article’s main argument doesn’t seem to rely on company loyalty. The idea is that the company’s overall effectiveness is improved by the cultural focus on coaching, which challenges assumptions and creates psychological safety.
This resonates with my own experience. My first software engineering jobs were for companies that had company-wide intern programs, but the teams I ended up on weren’t super invested in teaching/coaching. They were full of seniors who were convinced they knew everything. They were often unable to explain concepts to me and resistant to new ideas (that in hindsight were good ideas). Their ability to “do” was impacted by their inability to “teach”.
This, exactly. It makes me think of the Feynman quote of knowing you must not understanding a topic if you can’t reduce it to a 100 level course. It can be a bit of an ego check, but I had to level with a team once that if a Junior does poorly on this team, it would be more a reflection of this team than of the junior.
The other thing that’s lost here, is how insanely huge the software world is. I can have 15 years experience in a domain, and shift to a team where the tools are Just Different. Everything you put in place to support a Junior is also of huge benefit to someone coming from another language/domain/company. You see this a lot when people shift to and from startups and enterprise. Similarly for the shift from embedded technologies and web. Or product vs infra and ops.
Wow. Capitalism incentives run contrary to bettering other people. Who would have guessed that an ideology rooted in selfish individualism would do that? /s
Wait, no, this just in: companies can choose not to engage in exploitative capitalism and actually make life bearable for their employees.
Wait, no, I have just been informed that pension funds insist on maximum exploitation. Well, nothing to be done, people in the US are officially masochists.
Junior dev is not equal junior dev. There are people who started out programming as 10 year old kids. By the time they turn 20, if they’ve been diligently working on their hobby projects, they boast a decade of programming and debugging experience. On the other hand, some people leave university at age 25 and have no programming experience to speak of. If they ever get this far, they will be at a comparable level at age 35. This is why you have to choose your junior devs wisely. It’s all about the individual - there are some true gems among the youngsters, but you have to recognize them.
Your company needs to get rid of the silly junior / senior / staff distinction. It’s worse than the short-lived “rockstar” time, and I’m seriously disappointed that this disease is spreading world-wide. (Although given the zeitgeist, I’m half expecting full OR-1 to OF-10 soon)
The industry aligning on consistent, standardized levels across companies is one of the best things that we could achieve to improve software engineering as a professional discipline. I’m not asserting that the current zeitgeist is anywhere close to that, but it does at least seem to be moving in that way, especially in light of sites like https://levels.fyi and https://progression.fyi.
What is the actual problem that you have? What alternative do you propose?
In what way do you see this “improve software engineering as a professional discipline”?
If the consistency and standardization comes down to having a very low granularity of adjectives attached to job descriptions, what’s the gain? I can’t think of a single way where the sole knowledge that Bob Bobson is a “Senior SE” and joins my team would help right now.
You didn’t answer my questions and responded with non-sequiturs. Your response assumes that consistent leveling is not possible, which is fallacious. If you start from that position, it’s no surprise you feel that way.
Imagine that meaningful, standardized levels could be achieved, and please try to answer my questions. Consider it a fantasy if you wish. But being unwilling to consider the possibility means you’re just entrenched into your preconceived notion, in which case there’s no use in continuing the conversation.
Your first question was what my actual problem is. And the main one is that I don’t really see any problem this vague level naming does beyond giving HR departments some rough guidelines. Does that improve software engineering?
In my opinion, meaningful and standardized can’t be achieved here, in a way that helps one for actual products. Especially if it all boils down to a single rank/title. This reminds me a lot of ‘70s Dungeons & Dragons, where you’re called a “Lord” once your fighter reaches 9th level. And of course said warrior is equal proficient at wielding longswords as they’re awesome with glaive-guisarmes.
But in the real world, skills are not equally distributed. And to continue my fractal of stubbornness, I’m also not a fan of ranking those on a five star or 1 to 11 scale, as that’s literally too one-dimensional. I’ve worked with a lot of Java developers in the course of my career, and still would find it very hard to objectively rate someone’s grasp of “the language”. What could be meaningful for a project with a narrow scope, focused on umpteen existing APIs and a need for a quick on-ramp might not necessarily overlap with something where you start from a blank slate and a lot of design work and prototyping is needed. And yet another employer might need someone focused on a lot of nitty-gritty details because code reviews and security checks are a major part. Are these separate, sequential levels?
That’s what it boils down for me: Our industry isn’t uniform enough to provide a solid foundation on which you’d build a standard for measuring developer ability. And definitely not something on the level of junior/senior, white belt/black belt or tenderfoot/eagle.
First, thank you for the response. This is well considered and does answer my question.
So, what I interpret here is that your belief is that the “junior/senior/staff distinction is silly” because we don’t (yet) have a way to make the distinction useful to us. You may even believe that it’s entirely impossible to do so.
I think for me the difference is that I am considering the benefits that would be reaped if we could achieve consistent, standardized levels that have actual meaning. I don’t think that it’s simple, and to be honest, I highly doubt if anything close will be achieved within the next 10-20 years.
I can say that part of the difference in the way that you and I think is that I am less concerned with individual skills and more with impact, aptitude, etc. So, carrying along with your Java example for a moment, I don’t really care so much about an individual’s grasp of “Java the language” in the abstract, I care about their ability to gain the level of grasp that they need in any language (given sufficient time) to achieve their task at hand. I agree with you that a different depth of understanding is required for different tasks, but I also feel that depth of understanding for individual pieces of technology would be one of the easiest things to standardize on (with better certifications, no different from how we decide that civil engineers know enough to be granted a stamp with the power to impact hundreds of thousands of lives), but I also think that level of standardization isn’t particularly useful.
So, this is a lot of words to say, I mostly agree with a lot of your thoughts, but I would add a lot of “yets” and “untils”, because I don’t think it’s inevitable that things remain this way. Thinking about software engineering as more similar to actual engineering is the shift that I am imagining could be so impactful to our industry, but I also don’t think it’s something that is going to happen any time soon.
The industry aligning on consistent, standardized levels across companies is one of the best things that we could achieve to improve software engineering as a professional discipline.
The industry has no reliable way of grading people on those levels. One company’s junior is another company’s staff. The levels mean very little with no common base to agree on.
Plus it assumes a perfect level of meritocracy which doesn’t exist all around. I’ve personally seen very unskilled programmers — to the level where we had to fire them as the code was so subpar — rise to tech lead and then CTO in two years.
Abusing and subverting the levels doesn’t mean the levels are meaningless, it just means the meaning is being ignored. Saying someone was undeservedly promoted to tech lead and CTO inherently implies that the terms “tech lead” and “CTO” do have a proper meaning to you.
Even in a single company it depends on who the manager is and each person’s negotiation skill and drive.
I once participated in a technical interview for a senior dev (potential internal transfer) that couldn’t tell you the difference in complexity of searching for an element in an array vs a map. The worst part is I was asking those questions while not even senior myself at the time! It was a wakeup call that I really needed a raise and that the imposters are alive and well. This one came with a project director’s recommendation, the only reason we did the tech interview because on paper they were not a good fit either.
No reliable way yet, and your second paragraph is an indictment of exactly what happens when such standards do not exist, so you actually seem to be unintentionally arguing my point.
Something being difficult to achieve doesn’t mean we should throw up our hands and ignore it. Solving difficult problems is how we move forward.
This. I’ve worked both in companies with extremely rigid and well defined levels and those that were entirely flat. At least in my anecdotal experience the ones with well defined levels were far more pleasant to work in. The ones with a flat structure develop hard to articulate or combat “implicit levels” that are subject to cliques and relationships. Humans pretty naturally develop hierarchies, so I’ve found it’s better when they’re designed and not grown.
Aside from the articles statement that “maybe people who can’t teach shouldn’t do things”; which is easily rebuffed as teaching is an entirely separate skill from doing, great teachers can be terrible do-ers and vice-versa.
Juniors are a problem for the mercenary culture that companies have created by attempting to suppress wages of long term staff.
Namely, a Junior is an investment, you can get a 10/10 senior who knows your company inside and out. A new vanguard, a repository to store tacit, institutional knowledge; but no sufficiently trained junior who is “good enough” to be validated externally is going to stick around for an abysmal salary.
Even if a junior wanted to stick around for his/her mentors; those mentors likely move around often too- and the ones that don’t.. largely can’t due to being poor interviewees.
It’s exceedingly rare these days for people to be loyal to companies for more than 3-4 years.
So why would I as a company: invest 6-12 months of a seniors time when I have so little of it, for the benefit of someone else’s career? They’re just going to leave once trained after all; it’s pretty rare for companies to have a genuinely altruistic mindset- and it’s not cheap labour you’re getting back either.
The article’s main argument doesn’t seem to rely on company loyalty. The idea is that the company’s overall effectiveness is improved by the cultural focus on coaching, which challenges assumptions and creates psychological safety.
This resonates with my own experience. My first software engineering jobs were for companies that had company-wide intern programs, but the teams I ended up on weren’t super invested in teaching/coaching. They were full of seniors who were convinced they knew everything. They were often unable to explain concepts to me and resistant to new ideas (that in hindsight were good ideas). Their ability to “do” was impacted by their inability to “teach”.
This, exactly. It makes me think of the Feynman quote of knowing you must not understanding a topic if you can’t reduce it to a 100 level course. It can be a bit of an ego check, but I had to level with a team once that if a Junior does poorly on this team, it would be more a reflection of this team than of the junior.
The other thing that’s lost here, is how insanely huge the software world is. I can have 15 years experience in a domain, and shift to a team where the tools are Just Different. Everything you put in place to support a Junior is also of huge benefit to someone coming from another language/domain/company. You see this a lot when people shift to and from startups and enterprise. Similarly for the shift from embedded technologies and web. Or product vs infra and ops.
It’s not just new folks who benefit.
Wow. Capitalism incentives run contrary to bettering other people. Who would have guessed that an ideology rooted in selfish individualism would do that? /s
Wait, no, this just in: companies can choose not to engage in exploitative capitalism and actually make life bearable for their employees.
Wait, no, I have just been informed that pension funds insist on maximum exploitation. Well, nothing to be done, people in the US are officially masochists.
Junior dev is not equal junior dev. There are people who started out programming as 10 year old kids. By the time they turn 20, if they’ve been diligently working on their hobby projects, they boast a decade of programming and debugging experience. On the other hand, some people leave university at age 25 and have no programming experience to speak of. If they ever get this far, they will be at a comparable level at age 35. This is why you have to choose your junior devs wisely. It’s all about the individual - there are some true gems among the youngsters, but you have to recognize them.
Your company needs to get rid of the silly junior / senior / staff distinction. It’s worse than the short-lived “rockstar” time, and I’m seriously disappointed that this disease is spreading world-wide. (Although given the zeitgeist, I’m half expecting full OR-1 to OF-10 soon)
The industry aligning on consistent, standardized levels across companies is one of the best things that we could achieve to improve software engineering as a professional discipline. I’m not asserting that the current zeitgeist is anywhere close to that, but it does at least seem to be moving in that way, especially in light of sites like https://levels.fyi and https://progression.fyi.
What is the actual problem that you have? What alternative do you propose?
What does that solve?
In what way do you see this “improve software engineering as a professional discipline”?
If the consistency and standardization comes down to having a very low granularity of adjectives attached to job descriptions, what’s the gain? I can’t think of a single way where the sole knowledge that Bob Bobson is a “Senior SE” and joins my team would help right now.
You didn’t answer my questions and responded with non-sequiturs. Your response assumes that consistent leveling is not possible, which is fallacious. If you start from that position, it’s no surprise you feel that way.
Imagine that meaningful, standardized levels could be achieved, and please try to answer my questions. Consider it a fantasy if you wish. But being unwilling to consider the possibility means you’re just entrenched into your preconceived notion, in which case there’s no use in continuing the conversation.
Your first question was what my actual problem is. And the main one is that I don’t really see any problem this vague level naming does beyond giving HR departments some rough guidelines. Does that improve software engineering?
In my opinion, meaningful and standardized can’t be achieved here, in a way that helps one for actual products. Especially if it all boils down to a single rank/title. This reminds me a lot of ‘70s Dungeons & Dragons, where you’re called a “Lord” once your fighter reaches 9th level. And of course said warrior is equal proficient at wielding longswords as they’re awesome with glaive-guisarmes.
But in the real world, skills are not equally distributed. And to continue my fractal of stubbornness, I’m also not a fan of ranking those on a five star or 1 to 11 scale, as that’s literally too one-dimensional. I’ve worked with a lot of Java developers in the course of my career, and still would find it very hard to objectively rate someone’s grasp of “the language”. What could be meaningful for a project with a narrow scope, focused on umpteen existing APIs and a need for a quick on-ramp might not necessarily overlap with something where you start from a blank slate and a lot of design work and prototyping is needed. And yet another employer might need someone focused on a lot of nitty-gritty details because code reviews and security checks are a major part. Are these separate, sequential levels?
That’s what it boils down for me: Our industry isn’t uniform enough to provide a solid foundation on which you’d build a standard for measuring developer ability. And definitely not something on the level of junior/senior, white belt/black belt or tenderfoot/eagle.
First, thank you for the response. This is well considered and does answer my question.
So, what I interpret here is that your belief is that the “junior/senior/staff distinction is silly” because we don’t (yet) have a way to make the distinction useful to us. You may even believe that it’s entirely impossible to do so.
I think for me the difference is that I am considering the benefits that would be reaped if we could achieve consistent, standardized levels that have actual meaning. I don’t think that it’s simple, and to be honest, I highly doubt if anything close will be achieved within the next 10-20 years.
I can say that part of the difference in the way that you and I think is that I am less concerned with individual skills and more with impact, aptitude, etc. So, carrying along with your Java example for a moment, I don’t really care so much about an individual’s grasp of “Java the language” in the abstract, I care about their ability to gain the level of grasp that they need in any language (given sufficient time) to achieve their task at hand. I agree with you that a different depth of understanding is required for different tasks, but I also feel that depth of understanding for individual pieces of technology would be one of the easiest things to standardize on (with better certifications, no different from how we decide that civil engineers know enough to be granted a stamp with the power to impact hundreds of thousands of lives), but I also think that level of standardization isn’t particularly useful.
So, this is a lot of words to say, I mostly agree with a lot of your thoughts, but I would add a lot of “yets” and “untils”, because I don’t think it’s inevitable that things remain this way. Thinking about software engineering as more similar to actual engineering is the shift that I am imagining could be so impactful to our industry, but I also don’t think it’s something that is going to happen any time soon.
The industry has no reliable way of grading people on those levels. One company’s junior is another company’s staff. The levels mean very little with no common base to agree on.
Plus it assumes a perfect level of meritocracy which doesn’t exist all around. I’ve personally seen very unskilled programmers — to the level where we had to fire them as the code was so subpar — rise to tech lead and then CTO in two years.
Abusing and subverting the levels doesn’t mean the levels are meaningless, it just means the meaning is being ignored. Saying someone was undeservedly promoted to tech lead and CTO inherently implies that the terms “tech lead” and “CTO” do have a proper meaning to you.
Even in a single company it depends on who the manager is and each person’s negotiation skill and drive.
I once participated in a technical interview for a senior dev (potential internal transfer) that couldn’t tell you the difference in complexity of searching for an element in an array vs a map. The worst part is I was asking those questions while not even senior myself at the time! It was a wakeup call that I really needed a raise and that the imposters are alive and well. This one came with a project director’s recommendation, the only reason we did the tech interview because on paper they were not a good fit either.
No reliable way yet, and your second paragraph is an indictment of exactly what happens when such standards do not exist, so you actually seem to be unintentionally arguing my point.
Something being difficult to achieve doesn’t mean we should throw up our hands and ignore it. Solving difficult problems is how we move forward.
Flat organizations have their own problems caused by the absence of title distinctions. It’s not the utopian destination you may think it is.
This. I’ve worked both in companies with extremely rigid and well defined levels and those that were entirely flat. At least in my anecdotal experience the ones with well defined levels were far more pleasant to work in. The ones with a flat structure develop hard to articulate or combat “implicit levels” that are subject to cliques and relationships. Humans pretty naturally develop hierarchies, so I’ve found it’s better when they’re designed and not grown.
[1] THE TYRANNY of STRUCTURELESSNESS by Jo Freeman aka Joreen, 1970-1972