Is “Senior Software Developer” a Meaningless Title?(eduardobautista.com)
eduardobautista.com
Is “Senior Software Developer” a Meaningless Title?
https://www.eduardobautista.com/senior-software-developers/
71 comments
Agree. I work at a large company with very specific role guidelines for "Sr. Engineer" vs. a regular engineer. The main differences are not "programming" skills, although a Sr. Engineer is expected to have solid programming abilities.
This statements sticks out to me:
> You can argue that being a “senior” is more than just being a good programmer, but if the “junior” developer is more productive and is trusted with tough problems, at the very least we should reconsider what a “senior developer” really is.
Maybe the type of companies Eduardo has worked at, or the scope of his work, has left him thinking that the business solely values programming ability. But at my company, and at many other large companies, Sr. Engineers have a skillset that is nearly impossible for new graduates to have, because they aren't taught in college. In addition to technical prowess, these include:
* Operational best practices (how to monitor, deploy, and maintain systems)
* Project management (able to disambiguate a project and design it into achievable milestones with parallelizable work units)
* Historical context...like it or not, this is very valuable
* Knows how work happens across teams, such as best practices, pitfalls, technical strategies for minimizing coordination, etc.
* Can work and communicate clearly with stakeholders, PMs, customers, etc. to make the right product tradeoffs
* Know what matters and what doesn't when it comes to programming in a team setting, which is very different from solo programming
Almost all companies will value these skills, even if they have dropped the ball and don't have them listed as competencies.
> Yes, nobody wants to work with bad teammates, but refusing to acknowledge that there are great programmers who are also great teammates at the age of 22 is not the solution.
More than likely, those great programmers are recognized with salary increases. If they can't perform the tasks I listed above, they can be the best programmer in the world, but they don't belong as a Sr. Engineer. Which is fine, many people are happy not having to deal with all that "soft" stuff.
This statements sticks out to me:
> You can argue that being a “senior” is more than just being a good programmer, but if the “junior” developer is more productive and is trusted with tough problems, at the very least we should reconsider what a “senior developer” really is.
Maybe the type of companies Eduardo has worked at, or the scope of his work, has left him thinking that the business solely values programming ability. But at my company, and at many other large companies, Sr. Engineers have a skillset that is nearly impossible for new graduates to have, because they aren't taught in college. In addition to technical prowess, these include:
* Operational best practices (how to monitor, deploy, and maintain systems)
* Project management (able to disambiguate a project and design it into achievable milestones with parallelizable work units)
* Historical context...like it or not, this is very valuable
* Knows how work happens across teams, such as best practices, pitfalls, technical strategies for minimizing coordination, etc.
* Can work and communicate clearly with stakeholders, PMs, customers, etc. to make the right product tradeoffs
* Know what matters and what doesn't when it comes to programming in a team setting, which is very different from solo programming
Almost all companies will value these skills, even if they have dropped the ball and don't have them listed as competencies.
> Yes, nobody wants to work with bad teammates, but refusing to acknowledge that there are great programmers who are also great teammates at the age of 22 is not the solution.
More than likely, those great programmers are recognized with salary increases. If they can't perform the tasks I listed above, they can be the best programmer in the world, but they don't belong as a Sr. Engineer. Which is fine, many people are happy not having to deal with all that "soft" stuff.
> also working on projects that matter to the bottom line of the business
this is my problem with this sort of assessment : as an engineer, you don't get to pick which projec to work on. The politics of the company may end up making you look like you're worthless even though you could've provided so much more value working on something else.
this is my problem with this sort of assessment : as an engineer, you don't get to pick which projec to work on. The politics of the company may end up making you look like you're worthless even though you could've provided so much more value working on something else.
I don't agree with the author's stance on everything but I do think that programming skill is the most important skill for a senior software engineer/developer, for a few reasons:
- Code that is confusing/hard to approach for others (including future you) is bad code, so no "seniors" or "architects" that write crazy complex code aren't good at what they do -- true masters make complex things simple.
- Identifying the right problem to solve is not the engineers job -- this is squarely in business planning/project management domain, which is rightfully a different specialization
- Like the above, engineers shouldn't even be wasting time chasing down requirements, this is the job of project management, making people who have and specialized their craft over years spend time playing politics is wasteful.
I do recognize the need for the other skills you noted in a modern business, but maybe we should be calling those skills + programming skill something different. As far as I can tell with your response and others, a non-exhaustive list non-code metrics for "senior"s are:
- Business value understanding/delivery
- Guiding junior engineers
- Navigating politics
Maybe we can call that "Senior Engineering Project Lead" instead and make the required skill sets more distinguishable. The fact is that if you start optimizing for some of these other skills you're going to take a hit on architectural/programming skill -- time and attention is limited. If what the position requires is someone who spent 60% of their time honing their craft, and 10% learning to navigate politics and 30% focusing on business-level understanding, then maybe we should signify that with a more descriptive title. I guess the crux of my argument is that "Senior Software Engineer" is a misleading title.
As a side note, I think this is just yet another way for companies to extract more value from employees -- build in more and more requirements into an role denoted to be strictly for engineering, make another rung on the bullshit internal payment ladder to climb. I also would be more sympathetic to the "business impact" if more of the "business reward" was shared with those producing the value, and FAANG didn't actively collude in the last decade to reduce employee wages.
- Code that is confusing/hard to approach for others (including future you) is bad code, so no "seniors" or "architects" that write crazy complex code aren't good at what they do -- true masters make complex things simple.
- Identifying the right problem to solve is not the engineers job -- this is squarely in business planning/project management domain, which is rightfully a different specialization
- Like the above, engineers shouldn't even be wasting time chasing down requirements, this is the job of project management, making people who have and specialized their craft over years spend time playing politics is wasteful.
I do recognize the need for the other skills you noted in a modern business, but maybe we should be calling those skills + programming skill something different. As far as I can tell with your response and others, a non-exhaustive list non-code metrics for "senior"s are:
- Business value understanding/delivery
- Guiding junior engineers
- Navigating politics
Maybe we can call that "Senior Engineering Project Lead" instead and make the required skill sets more distinguishable. The fact is that if you start optimizing for some of these other skills you're going to take a hit on architectural/programming skill -- time and attention is limited. If what the position requires is someone who spent 60% of their time honing their craft, and 10% learning to navigate politics and 30% focusing on business-level understanding, then maybe we should signify that with a more descriptive title. I guess the crux of my argument is that "Senior Software Engineer" is a misleading title.
As a side note, I think this is just yet another way for companies to extract more value from employees -- build in more and more requirements into an role denoted to be strictly for engineering, make another rung on the bullshit internal payment ladder to climb. I also would be more sympathetic to the "business impact" if more of the "business reward" was shared with those producing the value, and FAANG didn't actively collude in the last decade to reduce employee wages.
> identifying the right problem to solve is not the engineers job
But the senior engineer has a vital role in advising which problems are solvable. Either in terms of technology, skill, time or budget. That input needs to start at the commencement of a project.
Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't.
> [and if] FAANG didn't actively collude in the last decade to reduce employee wages
I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.
But the senior engineer has a vital role in advising which problems are solvable. Either in terms of technology, skill, time or budget. That input needs to start at the commencement of a project.
Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't.
> [and if] FAANG didn't actively collude in the last decade to reduce employee wages
I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.
> But the senior engineer has a vital role in advising which problems are solvable. Either in terms of technology, skill, time or budget. That input needs to start at the commencement of a project.
> Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't.
I still think this makes sense if the problem is an engineering problem. The problem is rarely whether you can or can't do something (unless you're doing some suuuper cutting edge tech) -- it's whether you should or not, and that's a project management/business/product person's job to decide, when they draw up the plan for the project.
I know this isn't how it will work in the real world, but the senior engineer should be called on to clarify parts of the plan, not to start doing the planning & figuring out how to maximize business value. Once you start bringing in those other aspects, it's no longer about the engineering discipline -- so the job title should reflect that -- It's obvious that a "senior engineering project lead" knows why a particular requirement is in the functional requirements -- it's less clear to me (at least) that a "senior engineer", all I expect from that person is engineering ability.
Maybe it's just pedantry/semantics but it seems like a distinguishable difference to me.
> I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.
I can't argue with your context, but I bet FAANG's profits are also out of context compared to the companies you're thinking about in the UK as well. Tech is literally one of the US's biggest (if not biggest, I think the entertainment industry might be the biggest) export. Just because there was more money to go around doesn't mean what they did wasn't wrong and extremely employee-hostile.
As a side note, maybe you should move to another company/industry? No one is forcing you to be paid less, especially with 15 years of experience... Go to one of the companies with enough money to pay you lavishly.
> Here's my rough delineation: a Senior knows why a particular requirement is in the Func Req Doc. A Junior doesn't.
I still think this makes sense if the problem is an engineering problem. The problem is rarely whether you can or can't do something (unless you're doing some suuuper cutting edge tech) -- it's whether you should or not, and that's a project management/business/product person's job to decide, when they draw up the plan for the project.
I know this isn't how it will work in the real world, but the senior engineer should be called on to clarify parts of the plan, not to start doing the planning & figuring out how to maximize business value. Once you start bringing in those other aspects, it's no longer about the engineering discipline -- so the job title should reflect that -- It's obvious that a "senior engineering project lead" knows why a particular requirement is in the functional requirements -- it's less clear to me (at least) that a "senior engineer", all I expect from that person is engineering ability.
Maybe it's just pedantry/semantics but it seems like a distinguishable difference to me.
> I laughed at that. FAANG salaries are so out of context of most around the World that they are irrelevant. As a 15-year Senior in the UK I was earning $50,000 equivalent. And no stock options. I don't think FAANG salary ladders even start that low.
I can't argue with your context, but I bet FAANG's profits are also out of context compared to the companies you're thinking about in the UK as well. Tech is literally one of the US's biggest (if not biggest, I think the entertainment industry might be the biggest) export. Just because there was more money to go around doesn't mean what they did wasn't wrong and extremely employee-hostile.
As a side note, maybe you should move to another company/industry? No one is forcing you to be paid less, especially with 15 years of experience... Go to one of the companies with enough money to pay you lavishly.
When I started at my current company, Senior Developer titles were given out by management. They didn't have the capability or the information to judge people based on technical skills, and the title was mainly used as a perk to keep employees at the company to avoid having to retrain. I feel like this happens in a lot of places, and is probably the cause of what the author describes in the article.
I'm now a director at the same company, and I've laid out criteria for achieving the Senior role that developers seem to understand. It's now something that they can work towards instead of simply aging into, and it makes the title more meaningful.
Core criteria for a Senior Developer:
* Mastery of their toolset, maybe not 100% but enough to solve any problem.
* Ability to take an entire project from start to completion without assistance. This doesn't mean they don't get any assistance or can't ask for help, but if no one is available, they should be able to arrive at a sensible solution to any problem.
* Understand our business, and prioritize decisions that have a net benefit for the business / team. Balance personal desires for perfection against the pragmatic needs of the customer and our business. We're here to do a job.
* Uses their time effectively. If I see a developer who has a few days of downtime between booked client work, I want to see them take on a task or learn a skill that will benefit the business.
* Client facing attitude and communication that reflects positively on the team. We don't put developers in front of clients often, but each should be able to provide notes in a JIRA to help a client understand an issue or clarify available options. Clear, concise, polite and helpful.
These are skills that I think the average developer would gradually learn in five years on the job, but having them spelled out helps junior and mid level devs understand what is important to the business.
I'm now a director at the same company, and I've laid out criteria for achieving the Senior role that developers seem to understand. It's now something that they can work towards instead of simply aging into, and it makes the title more meaningful.
Core criteria for a Senior Developer:
* Mastery of their toolset, maybe not 100% but enough to solve any problem.
* Ability to take an entire project from start to completion without assistance. This doesn't mean they don't get any assistance or can't ask for help, but if no one is available, they should be able to arrive at a sensible solution to any problem.
* Understand our business, and prioritize decisions that have a net benefit for the business / team. Balance personal desires for perfection against the pragmatic needs of the customer and our business. We're here to do a job.
* Uses their time effectively. If I see a developer who has a few days of downtime between booked client work, I want to see them take on a task or learn a skill that will benefit the business.
* Client facing attitude and communication that reflects positively on the team. We don't put developers in front of clients often, but each should be able to provide notes in a JIRA to help a client understand an issue or clarify available options. Clear, concise, polite and helpful.
These are skills that I think the average developer would gradually learn in five years on the job, but having them spelled out helps junior and mid level devs understand what is important to the business.
One thing that I would say is missing from your list is that a senior developer should actively be working with junior developers. Not necessarily as a mentor, but they should be available to help less senior people improve their craft.
I agree this is an important skill (and attitude), but whether it's a core requirement for senior probably depends on the size of your shop. Senior devs who are keen to mentor, passionate about fixing organizational flaws (process development), and are good at managing upwards are starting to tick boxes for Team Lead or engineering management.
If the team is big enough to support it, I think it's acceptable to have a senior dev who doesn't give a lot back in terms of mentoring but handles their projects and doesn't create messes.
If the team is big enough to support it, I think it's acceptable to have a senior dev who doesn't give a lot back in terms of mentoring but handles their projects and doesn't create messes.
What's the next step up from Sr then?
I agree that you don't have to mentor people but I think that makes you way less effective than you would be normally. Now you may be making a distiction on working with others and mentoring but I think it's the same, if your helping others become more effective at any task thats mentoring.
Ive also seen a tendency of people who are excellent solo to make broader scope problems due to less trust or just less communication with others.
I'm also always very worried when I hear a piece of software was written by one person.
I agree that you don't have to mentor people but I think that makes you way less effective than you would be normally. Now you may be making a distiction on working with others and mentoring but I think it's the same, if your helping others become more effective at any task thats mentoring.
Ive also seen a tendency of people who are excellent solo to make broader scope problems due to less trust or just less communication with others.
I'm also always very worried when I hear a piece of software was written by one person.
Some people just don't enjoy teaching that much. I think generally most people get satisfaction from helping others, but some devs just seem to prefer working mostly on their own. They still have to write pragmatic and maintainable code (the "dont make messes" part), and they don't level up others in the business, but they can still be incredibly valuable.
In smaller shops, there really isn't anywhere "further" to go past Senior unless you want to take on leadership of other devs. And it makes sense, in a lot of cases once you get to a certain level of experience the most valuable thing you can do is pass on some knowledge and act as a multiplier for others.
In smaller shops, there really isn't anywhere "further" to go past Senior unless you want to take on leadership of other devs. And it makes sense, in a lot of cases once you get to a certain level of experience the most valuable thing you can do is pass on some knowledge and act as a multiplier for others.
You can lead without being a manager, eg lead by example, lead without force, lead by halping when asked, or providing guidance when asked. That's all mentoring. That's all pure technical. We may be agreeing.
But I wouldn't want to be in a place where there was just good at coding was the end of my growth.
But I wouldn't want to be in a place where there was just good at coding was the end of my growth.
At some point your effectiveness only comes from being a force multiplier - by helping other people getting ahead.
That is impossible for most, where would you get all juniors? People are only junior for a couple of years in a 40 year career, should we assign a team of seniors to mentor each junior?
Interestingly, the criteria that apply to a Senior Developer can be also applied to a Technical Co-founder and a Software Contractor. Essentially, someone who is independent enough to be a Senior Developer, should be also independent enough to run his own business, if he only wanted that.
I agree, at least to have the technical and customer facing skills. Running a consulting business also requires marketing and sales skills and I don't know if it makes sense to require those for a senior developer position.
"Uses their time effectively. If I see a developer who has a few days of downtime between booked client work, I want to see them take on a task or learn a skill that will benefit the business."
No one can keep up the context switching for extended periods of time, but some are better at faking it than others.
"I'm now a director at the same company"
Right.
No one can keep up the context switching for extended periods of time, but some are better at faking it than others.
"I'm now a director at the same company"
Right.
Sure, but not for the reasons the (really light) blogpost suggests.
It's not about seniority in a specific technology or in sitting at a particular desk for enough years.
It's about judgement and experience. Yes, some people never acquire these things, and some people have an unusually large amount of it from the get-go.
But when you've been in the trenches for a decade, you (tend to) simply know things a junior doesn't. You know where you spend your efforts, and which red herrings to avoid. You know how to navigate the systems, the politics. How to interface with colleagues. And so on.
It's not about seniority in a specific technology or in sitting at a particular desk for enough years.
It's about judgement and experience. Yes, some people never acquire these things, and some people have an unusually large amount of it from the get-go.
But when you've been in the trenches for a decade, you (tend to) simply know things a junior doesn't. You know where you spend your efforts, and which red herrings to avoid. You know how to navigate the systems, the politics. How to interface with colleagues. And so on.
The article is misleading. It should say "Seniority is not about time spent at a company, but skill level."
If you are "senior" only through being with one company for a long time, you will have a very hard time interviewing and switching jobs. If you are "senior" through skill, you will have a very easy time and feel comfortable that you can find a similar job should the company go under / you are fired / etc. Likewise, people won't resent you for the title.
I actually thought about it recently. One of our devs just left for a "Senior" position - this kid is bright and has a CS degree. He recommended me for a "Senior Lead" position - I declined, because I have gaps in my knowledge that preclude me from doing that. (#humblebrag)
It's very easy to "jump past your skill level" in terms of positions in IT atm, but it costs you. Mainly it costs you like any other lie - you spend more time keeping up appearances than really improving. When you are at an "appropriate" position, you don't feel bad admitting you don't know something.
That's not to say that some worthwhile people don't get promoted - it's easy to get stuck in a position, IF you are unwilling to leave your company. There is also getting stagnant - jumping roles gives you more exposure, but it needs to be exposure you can handle.
If you are "senior" only through being with one company for a long time, you will have a very hard time interviewing and switching jobs. If you are "senior" through skill, you will have a very easy time and feel comfortable that you can find a similar job should the company go under / you are fired / etc. Likewise, people won't resent you for the title.
I actually thought about it recently. One of our devs just left for a "Senior" position - this kid is bright and has a CS degree. He recommended me for a "Senior Lead" position - I declined, because I have gaps in my knowledge that preclude me from doing that. (#humblebrag)
It's very easy to "jump past your skill level" in terms of positions in IT atm, but it costs you. Mainly it costs you like any other lie - you spend more time keeping up appearances than really improving. When you are at an "appropriate" position, you don't feel bad admitting you don't know something.
That's not to say that some worthwhile people don't get promoted - it's easy to get stuck in a position, IF you are unwilling to leave your company. There is also getting stagnant - jumping roles gives you more exposure, but it needs to be exposure you can handle.
I would argue that you should always be aiming for just past your current skill level. Nothing like jumping in the deep end for leveling up quickly.
The further I get up the ladder, the more I realize that everyone is faking it.
The further I get up the ladder, the more I realize that everyone is faking it.
Let me preface what I am about to say by stating that I live in a major metropolitan area in the US that is not the West Coast or NYC. So when I refer to salaries below, not only is it not a humble brag, it’s below starting total comp for a developer one to three years out of school at a FAANG. Now on to the post....
Titles have been absolutely meaningless my entire 20+ year career.
1. My first job was officially a computer operator that I took just to get out of the small town where I graduated but within three months, I was developing a data entry system in C that doubled the size of the company. I stayed for three years still officially a “computer operator”.
2. I stayed at the next company for nine years, my career and my salary stagnated after the second, I have no idea what my title was.
3. I left and as far as I know, my title at my next job was just “software engineer” and I was paid about what a mid level developer would make. I purposefully took this job to pivot away from being a bit twiddler to being an “Enterprise Developer”.
4. Working for what was at the time a Fortune 10 company, my title was “Senior Software Engineer” but I really honestly couldn’t call myself that until I left three years later. I was still paid like a Mid level developer just slightly more.
4. I found out about two years in that I wasn’t considered a “Senior Software Engineer” at my next small company, even though by now I was making the low end of what a Sr. software Engineer should be making.
5. Changed jobs again two years later and was officially the dev lead/“Senior Software Architect” of a medium size non software company with a small software department but making about the median for what a Sr. Software Engineer should be making.
6. I purposefully self demoted, at my current job two years later to “just” a “Sr. Software Engineer” at a small company so I could spend time filling in some technical gaps to prepare for my next role as an overpriced “Cloud Consultant”/“Digital Transformation Consultant”. But I’m making about the median salary of an “Architect”.
Titles have been absolutely meaningless my entire 20+ year career.
1. My first job was officially a computer operator that I took just to get out of the small town where I graduated but within three months, I was developing a data entry system in C that doubled the size of the company. I stayed for three years still officially a “computer operator”.
2. I stayed at the next company for nine years, my career and my salary stagnated after the second, I have no idea what my title was.
3. I left and as far as I know, my title at my next job was just “software engineer” and I was paid about what a mid level developer would make. I purposefully took this job to pivot away from being a bit twiddler to being an “Enterprise Developer”.
4. Working for what was at the time a Fortune 10 company, my title was “Senior Software Engineer” but I really honestly couldn’t call myself that until I left three years later. I was still paid like a Mid level developer just slightly more.
4. I found out about two years in that I wasn’t considered a “Senior Software Engineer” at my next small company, even though by now I was making the low end of what a Sr. software Engineer should be making.
5. Changed jobs again two years later and was officially the dev lead/“Senior Software Architect” of a medium size non software company with a small software department but making about the median for what a Sr. Software Engineer should be making.
6. I purposefully self demoted, at my current job two years later to “just” a “Sr. Software Engineer” at a small company so I could spend time filling in some technical gaps to prepare for my next role as an overpriced “Cloud Consultant”/“Digital Transformation Consultant”. But I’m making about the median salary of an “Architect”.
For a long time I had no idea what senior meant and whether I was it or not. It does seem it means something different depending on the company you work for. Some companies have a "medior" between junior and senior, others don't care about such titles at all.
It's certainly not just about programming skill or how fast you can fix bugs. Or at least the programming skill it's about is about more than writing code and solving problems. I was great at solving problems in university, but I was not remotely senior.
Seniority is, as far as I understand, often about carrying a project, keeping an eye on not just what the customer or PO says they want, but on what they need or what the project needs. On code quality, on what needs to be refactored and whether or not now is the right time for it. On how to organise and divide various modules. On keeping it testable, deployable, performant, and most importantly, maintainable.
It's entirely possible to be good at those things but worse or slower at fixing bugs or writing features. I've seen cowboys who develop complex stuff at an insane speed, but leave an unmaintainable mess.
Programming is not a one-dimensional thing.
It's certainly not just about programming skill or how fast you can fix bugs. Or at least the programming skill it's about is about more than writing code and solving problems. I was great at solving problems in university, but I was not remotely senior.
Seniority is, as far as I understand, often about carrying a project, keeping an eye on not just what the customer or PO says they want, but on what they need or what the project needs. On code quality, on what needs to be refactored and whether or not now is the right time for it. On how to organise and divide various modules. On keeping it testable, deployable, performant, and most importantly, maintainable.
It's entirely possible to be good at those things but worse or slower at fixing bugs or writing features. I've seen cowboys who develop complex stuff at an insane speed, but leave an unmaintainable mess.
Programming is not a one-dimensional thing.
When I was twenty-five I didn't think experience was all that important and chaffed at the fact that it was so considered by others. Today I think the opposite.
Was I right back then or I am right now? Will the author of this post feel the same way he does now in ten more years?
We can all write blog posts filled with earnest arguments and anecdotes, but unless there is some sort of good data around to look at I doubt anyone's mind is going to be changed.
Was I right back then or I am right now? Will the author of this post feel the same way he does now in ten more years?
We can all write blog posts filled with earnest arguments and anecdotes, but unless there is some sort of good data around to look at I doubt anyone's mind is going to be changed.
I think this is something that is timeless and universal. At least now we have experience to back up our valuation. When we were young what did we have? Some basic logic that we spent a small amount of time thinking through?
It's already well understood that "senior" and other titles and even total years of experience say very little about an individual's level of ability as a software developer. Most software development teams ask stringent coding questions during job interviews for precisely this reason.
When my team interviews junior engineers we mainly focus on coding questions. When we interview senior engineers we tend to spend about half the time on design questions, many of which involve no coding at all.
This is because the important difference between a junior and senior engineer is not coding skill -- it is the ability to implement solutions that work properly, fulfill the requirements, and are scalable and fault tolerant.
Junior candidates can sometimes do that, but most of the time they don't know when a design lacks fault tolerance or has scalability problems. When design flaws are pointed out, they don't know how to fix them or how to defend them as better trade-offs compared to the alternatives. It takes a bit experience to be able to do that -- especially experience fixing things that went wrong.
This is because the important difference between a junior and senior engineer is not coding skill -- it is the ability to implement solutions that work properly, fulfill the requirements, and are scalable and fault tolerant.
Junior candidates can sometimes do that, but most of the time they don't know when a design lacks fault tolerance or has scalability problems. When design flaws are pointed out, they don't know how to fix them or how to defend them as better trade-offs compared to the alternatives. It takes a bit experience to be able to do that -- especially experience fixing things that went wrong.
I would go even further, my last two jobs, I was asked no coding questions.
Of course, by the time you are senior, your software dev abilities should be a smaller piece of what you do. Making the business succeed is your job now. Sometimes that is coding. Sometimes that is making sure you don't code the wrong thing. Sometimes it is mentoring others, or training the other teams on details of the product. Could be gathering requirements from stakeholders, or interviewing customers. Could be sales support, team leadership, or other organizational needs.
Sure, every senior dev can code. But 'Senior' isn't about being the best coder... it is about being helpful with the bigger picture.
Sure, every senior dev can code. But 'Senior' isn't about being the best coder... it is about being helpful with the bigger picture.
True. Levels in job titles are in part virtue signaling mechanisms within a corporation.
The issue with "senior" in tech is that it has two different meanings. You can be a senior engineer in the sense that you've been in the industry for a long period of time and have the kind of deep expertise and understanding that only comes with having spent a long time immersed in something (you've seen some shit), but that's entirely different than having a job title of "senior engineer."
For example, at the SF-area non-FAANG unicorn I work at, if you are L5 then you are considered a senior engineer by virtue of your job title, but when the directors and heads of XYZ department refer to the senior engineers, they mean L6 (staff engineer) and above.
FWIW, my own opinion is that if you have less than 10 years' experience, you are not a senior engineer, regardless of what your job title says. You might still be a complete superstar and understand algorithms inside and out and be able to produce efficient, bug-free code that compiles on the first try, and that's great, but there is no substitute for the wisdom learned over time, particularly if you're going to be expected to deal with people as part of your role.
For example, at the SF-area non-FAANG unicorn I work at, if you are L5 then you are considered a senior engineer by virtue of your job title, but when the directors and heads of XYZ department refer to the senior engineers, they mean L6 (staff engineer) and above.
FWIW, my own opinion is that if you have less than 10 years' experience, you are not a senior engineer, regardless of what your job title says. You might still be a complete superstar and understand algorithms inside and out and be able to produce efficient, bug-free code that compiles on the first try, and that's great, but there is no substitute for the wisdom learned over time, particularly if you're going to be expected to deal with people as part of your role.
> [...] but there is no substitute for the wisdom learned over time [...]
This is so very true. And, took me many years before I finally learned this!
Fortunately, early on in my career, I had the opportunity to work with some very senior developers. Even though I was a self-proclaimed 'rock star', they managed to open my eyes as to how much I still had to learn.
This is so very true. And, took me many years before I finally learned this!
Fortunately, early on in my career, I had the opportunity to work with some very senior developers. Even though I was a self-proclaimed 'rock star', they managed to open my eyes as to how much I still had to learn.
So true. "10 years of experience" means nothing. It could mean "10 years of in-depth focus on X subfield and skills" or "1 year of work experience repeated 10 times."
well put. I have interviewed way too many "experienced" candidates who progressed very little since 2 years out of college.
It's as if people just get way too complacent and lazy to keep learning beyond the 2-3 years point, where the learning curve starts flattening.
It's as if people just get way too complacent and lazy to keep learning beyond the 2-3 years point, where the learning curve starts flattening.
Could it be that people are not actually complacent and lazy, and instead were simply never trained or upskilled by employers who didn't see any business incentive in doing so, and simply squeezed every last bit of juice out of the employee's existing skillset?
Not only is the title meaningless, but the usage of it seems to be changing over time. When I started in the field (~2004) Senior felt like it was a 10 years of experience bar. Maybe this was just fallout from the .combomb, but it felt like something more real. Something where you've been through multiple release cycles, and have good instincts.
Now it does seem to be a butt-in-chair measurement, and 5 years seems even on the higher end for what I hear is senior these days. I've seen some job applications for senior say 2-5 years of experience even.
I feel like a part of this is related to compensation though, as companies love to say they anchor to x percentile of job title for their starting offer. In order to pay someone more, you have to inflate their title. Skill, other than interviewing skill, seems to have little to do with it.
Now it does seem to be a butt-in-chair measurement, and 5 years seems even on the higher end for what I hear is senior these days. I've seen some job applications for senior say 2-5 years of experience even.
I feel like a part of this is related to compensation though, as companies love to say they anchor to x percentile of job title for their starting offer. In order to pay someone more, you have to inflate their title. Skill, other than interviewing skill, seems to have little to do with it.
Just an alternate bit of anecdata, I was a junior dev around the same time and senior titles seemed to start in the 3-5 years of experience range near where I lived.
> 5 years seems even on the higher end for what I hear is senior these days.
Funny, because 2-3 years seems to be on the low end for "junior".
Funny, because 2-3 years seems to be on the low end for "junior".
Titles are meaningless in general. They exist just to put you on the "career ladder" type threadmill where the next title (or "level") is withheld from you until you put what your employer considers to be your "very best" to obtain it, or you're just pals with your boss, or good at self promotion. In fact I'd say that the latter two things are more conducive to obtaining a fancier title if you choose to play the game.
The corollary of all this is: pay zero attention to titles. Only two things are important and material:
1. Whether you enjoy the job
2. How much you get paid to do the job
That's it. Titles are cheap. Do not get taken by this scam. Focus on the two "fundamentals" listed above, and "titles" will take care of themselves in time. Also, don't stay with the same employer for too long unless you like to work harder for less.
The corollary of all this is: pay zero attention to titles. Only two things are important and material:
1. Whether you enjoy the job
2. How much you get paid to do the job
That's it. Titles are cheap. Do not get taken by this scam. Focus on the two "fundamentals" listed above, and "titles" will take care of themselves in time. Also, don't stay with the same employer for too long unless you like to work harder for less.
Titles signify expectations, and expectations are far from meaningless.
For example, achievements that would get a junior engineer promoted are expected to be the normal level of achievement for senior engineers.
For example, achievements that would get a junior engineer promoted are expected to be the normal level of achievement for senior engineers.
>> Titles signify expectations
Only tangentially, and only within a particular organization. That's how they justify the treadmill to you. It is not possible to evaluate "expectations" (or "performance" for that matter) without bias. Titles do not translate across companies. And the most senior person quite often contributes the least to the success of the project. They're often viewed as "having paid their dues", but really, they've mostly been in the right place at the right time. Exceptions are few and far between.
Shit, at one point I was "led" by a CTO who couldn't architect his way out of a wet paper bag and showed up at work for a day every two weeks. Very "senior", yet totally worthless.
Only tangentially, and only within a particular organization. That's how they justify the treadmill to you. It is not possible to evaluate "expectations" (or "performance" for that matter) without bias. Titles do not translate across companies. And the most senior person quite often contributes the least to the success of the project. They're often viewed as "having paid their dues", but really, they've mostly been in the right place at the right time. Exceptions are few and far between.
Shit, at one point I was "led" by a CTO who couldn't architect his way out of a wet paper bag and showed up at work for a day every two weeks. Very "senior", yet totally worthless.
"Senior" in this industry typically means "not a beginner". You should not be right out of school if you are applying for these positions. And "experience required" is certainly a useful concept.
But "senior" isn't really a good name for it, because people with only a few years of experience are not trusted to make big decisions and build (or lead) big things, which is what "senior" tends to mean in other contexts. The title is therefore a bit deceptive. But I'm not sure what to replace it with.
And finally, to be fair, there are a few places where "senior" is fairly senior. At Google, it's two promotions up from entry level, and I seem to recall Amazon listing it with seven years of required experience, which is getting up there.
But "senior" isn't really a good name for it, because people with only a few years of experience are not trusted to make big decisions and build (or lead) big things, which is what "senior" tends to mean in other contexts. The title is therefore a bit deceptive. But I'm not sure what to replace it with.
And finally, to be fair, there are a few places where "senior" is fairly senior. At Google, it's two promotions up from entry level, and I seem to recall Amazon listing it with seven years of required experience, which is getting up there.
When I was a jr developer I worked on small tasks. Fix some random bug here, update documentation etc. but it gave me insight to how the company did stuff and also let me prove that I can make contributions without breaking stuff. Later people started asking my opinion on stuff because I had been working so closely with the code base. Eventually I was promoted to sr and I began directing the workflow of jr devs, deciding on projects etc. And now as an architect I work directly with business stakeholders to identify issues and design solutions. I work with the sr developers and they do the bulk of the more advanced work, where the jrs work on smaller pieces that I used to do. We have a pretty good system and there are clear differences in our roles and skill sets.
Here’s how I got ‘senior’
‘Can you give me a raise?’
‘Well we’ve had budget cutbacks, etc’
‘Okay, how about if I get a senior title?’
‘Sure, that doesn’t cost anything’
Eight months later, I left for a place that paid me a senior salary.
‘Can you give me a raise?’
‘Well we’ve had budget cutbacks, etc’
‘Okay, how about if I get a senior title?’
‘Sure, that doesn’t cost anything’
Eight months later, I left for a place that paid me a senior salary.
Been there, done that, got the 'raise'.
It was fun.
It was fun.
If a company calls an "senior" to an engineer who sat in the seat for 8 years but is otherwise identical to the 2-year non-senior, then yes, it is meaningless.
I have not seen anybody use the term that way though.
It's the difference between SVP and VP: the former has greater skill/judgment/foresight/leadership and therefore greater authority/responsibility than the latter (possibly due to greater experience and career length but possibly not).
I have not seen anybody use the term that way though.
It's the difference between SVP and VP: the former has greater skill/judgment/foresight/leadership and therefore greater authority/responsibility than the latter (possibly due to greater experience and career length but possibly not).
I was given that title after 4 years of being with the company. Then they took it away because it was just a title and meant nothing. No extra pay either. Sounds good on a resume though. I complained about it and got fired for my troubles. They had a 90% turn-a-round rate and that is how they saved money using new people without raises.
I used to work at a place that did this and know other people that have too. Not necessarily over job titles, but generally pushing people out over stupid shit to keep salaries low.
I just can’t imagine that is more profitable in the long run. The overhead of constantly training new people has to cost more than giving raises..
I just can’t imagine that is more profitable in the long run. The overhead of constantly training new people has to cost more than giving raises..
They didn't train them. Just gave them a book on SQL Server and wanted them to be a DBA. So we had database problems. I had to fix the programming issues as a super debugger but spaghetti code is hard to fix esp when it isn't documented.
Titles are useless when comparing between companies. They're quite useful when comparing within the same company.
They aren't useless. You cannot expect a one-to-one mapping between titles at different companies, but titles are a general indication of what is expected from an employee at that level.
Having been both the "Senior Software Developer" and in management, it's hard to avoid HR policies that take tenure and seniority into account. Like it or not, positions need to be bucketed to drive things like pay grade, salary, etc.
That said, whenever possible I drive title based on how productive one makes other people. I don't expect a Junior developer to make the team more effective. I do expect seniors, principals, chiefs, etc to do so. If you are a Principal or Chief, you better be able to make your whole team much more productive.
It isn't about the coding skill of that person. It's about how the decisions they make affect the rest of the team. In the end, no one person, no matter how good can do it all. Making other people more effective is the hard part that I wish more devs focused on.
That said, whenever possible I drive title based on how productive one makes other people. I don't expect a Junior developer to make the team more effective. I do expect seniors, principals, chiefs, etc to do so. If you are a Principal or Chief, you better be able to make your whole team much more productive.
It isn't about the coding skill of that person. It's about how the decisions they make affect the rest of the team. In the end, no one person, no matter how good can do it all. Making other people more effective is the hard part that I wish more devs focused on.
Well, it depends on the company. But as a rule, said titles are:
1. Entirely meaningless between companies, since different companies have different ideas as to what counts as junior, midweight or senior respectively. For instance, a senior at Google and a senior at a small agency are a million miles apart.
2. If the company isn't a tech company or technically minded, they're probably meaningless within said organisation too. The most accurate thing you can say about 'seniors' is that they're usually the more experienced web developers in the company, whatever more experienced actually means in said case.
But yeah, meaningless between companies, meaningless in ones which aren't tech savvy and don't take them seriously, maybe meaningful at FAANG type companies.
1. Entirely meaningless between companies, since different companies have different ideas as to what counts as junior, midweight or senior respectively. For instance, a senior at Google and a senior at a small agency are a million miles apart.
2. If the company isn't a tech company or technically minded, they're probably meaningless within said organisation too. The most accurate thing you can say about 'seniors' is that they're usually the more experienced web developers in the company, whatever more experienced actually means in said case.
But yeah, meaningless between companies, meaningless in ones which aren't tech savvy and don't take them seriously, maybe meaningful at FAANG type companies.
The problem with this article, it talks about years of experience vs. actual experience. The title is relevant when properly defined.
Senior Engineers have the following traits.
- Self-motivated - They need a little direction on knowing what's important to focus on. Just because you're "working", doesn't mean you're working on what's important. - Organized - Being organized is an important factor in such a title. As a senior engineer, you're going to be leading others and if you're not organized, then you're not going to be very effective at leading. - Diverse experience - Senior engineers should have diverse experience in the industry. They've experienced building systems from the ground up, scaling them out, learning what's important to build a product that is maintainable, etc. - Keeps technology aligned with business - We write software to support the business. This means being able to identify what's important and a priority. - Strong communication - To be clear, I'm not just talking about writing skill. I'm talking about the ability to communicate status, level set expectations, communicate during times of trouble and more. - Deals with pressure - A lot of junior engineers tend to "react" to everything when the pressure is on. The above items help people deal with pressure. - Leadership skills - I touched on this, but I wanted to be very clear. Being able to influence, lead, organize, etc are all certainly senior engineering skills.
I was once that 19 year old engineer at a company who thought I demanded a higher title, more money etc. I get that feeling of pride and respect you have for yourself. That being said, I also really came to understand my shortcomings when I was around 29-30.
There's on very important thing I want to point out. I worked with people who had 20 years of experience, but were not that smart. I wouldn't classify them as "Senior" at all. They would argue "years of experience" and I would counter it with actual experience. If you're 20 years of experience was dealing with one product, on one team at one company, you screwed yourself out of actual experience.
Senior Engineers have the following traits.
- Self-motivated - They need a little direction on knowing what's important to focus on. Just because you're "working", doesn't mean you're working on what's important. - Organized - Being organized is an important factor in such a title. As a senior engineer, you're going to be leading others and if you're not organized, then you're not going to be very effective at leading. - Diverse experience - Senior engineers should have diverse experience in the industry. They've experienced building systems from the ground up, scaling them out, learning what's important to build a product that is maintainable, etc. - Keeps technology aligned with business - We write software to support the business. This means being able to identify what's important and a priority. - Strong communication - To be clear, I'm not just talking about writing skill. I'm talking about the ability to communicate status, level set expectations, communicate during times of trouble and more. - Deals with pressure - A lot of junior engineers tend to "react" to everything when the pressure is on. The above items help people deal with pressure. - Leadership skills - I touched on this, but I wanted to be very clear. Being able to influence, lead, organize, etc are all certainly senior engineering skills.
I was once that 19 year old engineer at a company who thought I demanded a higher title, more money etc. I get that feeling of pride and respect you have for yourself. That being said, I also really came to understand my shortcomings when I was around 29-30.
There's on very important thing I want to point out. I worked with people who had 20 years of experience, but were not that smart. I wouldn't classify them as "Senior" at all. They would argue "years of experience" and I would counter it with actual experience. If you're 20 years of experience was dealing with one product, on one team at one company, you screwed yourself out of actual experience.
[deleted]
"Senior Engineer" titles have a very specific and useful role in my experience - you can avoid the Peter Principle if people are rewarded for a job well done not with a change of role, but with recognition/prestige and a pay raise. This also serves as a useful tool for managers who want to make sure every team has a certain proportion of "seasoned coders".
Companies that don't have a Senior Engineer title tend to promote good engineers into management roles where they are often quite mediocre.
Companies that don't have a Senior Engineer title tend to promote good engineers into management roles where they are often quite mediocre.
I've worked for 8 years professionally.
The title of Senior is usually granted to people who are able to be capable of writing software without needing someone to watch over them daily.
They may ask questions or talk to their peers about problems, but unlikely juniors, they will be capable of finding out solutions to problems.
The title of Senior is usually granted to people who are able to be capable of writing software without needing someone to watch over them daily.
They may ask questions or talk to their peers about problems, but unlikely juniors, they will be capable of finding out solutions to problems.
From my experience, most promotions are a salary band change.
The company is willing to pay you more because:
1. They believe you will be able get a 'senior' band offer at a competing employer.
2. They believe that either you are worth the senior band pay or that you leaving will cost them more than the senior band pay.
The company is willing to pay you more because:
1. They believe you will be able get a 'senior' band offer at a competing employer.
2. They believe that either you are worth the senior band pay or that you leaving will cost them more than the senior band pay.
So, as a counterargument, I was recently promoted to senior software engineer at my current job. I've been with the company for two years and out of college for the same amount of time (I'm 24). Where I work, it's treated as an ability to deliver impact at a team level. Whether that be through technical contribution or leadership. For me, I found a niche in being a serial anchor for the team which led me to take on extra responsibility faster. That, in turn, led to me delivering a team-wide impact in a substantially reduced amount of time compared to some of my coworkers.
In some places, yes, the senior role is somewhat useful and based on time-in-job. In others, it's based on your impact to those around you and the larger the impact, the more "senior" you are.
In some places, yes, the senior role is somewhat useful and based on time-in-job. In others, it's based on your impact to those around you and the larger the impact, the more "senior" you are.
Titles mean different things at different companies; heck sometimes they mean different things per department. I always look for achievements, they're a better metric for seniority.
[deleted]
It's almost guaranteed to be useless considering I've gotten recruiting emails for 12+ years experience as a junior.
Getting recruitment emails doesn't mean anything. Some recruiters just mail everybody. Getting hired is what matters.
“Senior” is a mid-level programmer in most hierarchies. It’s regularly given after 3-5 years of experience.
I don’t think that’s either good or bad. Just the way it is.
I don’t think that’s either good or bad. Just the way it is.
tonetheman(1)
Does Betteridge's law of headlines apply here?
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
Betteridge’s law always applies - and whenever you bring it up in HN comments you invariably get downvoted.
Probably because it's predictable and therefore boring. Most people got the message about Betteridge years ago and headline writers generally avoid it. It's no longer the kind of problem that needs to be called out every single time it appears.
It seems as though the author's "juniorness" is showing through while writing this. In particular, the assertion that "programming skill is the most important skill for senior developer". I'm not sure that's true. You cannot write code in a vacuum; software development requires communication and understanding of the business to ensure you're solving the right problem. Doesn't matter how great your code is, if you write a solution to the wrong problem, you provide zero value. At companies where seniority is done well (FAANG, etc.) your performance is measured not just on the quality of your code, but the impact you provide to the business: this includes code quality, but also working on projects that matter to the bottom line of the business, enabling teammates to do their best work, bringing in new people, basically acting as a multiplier force.