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.
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 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.
- 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.
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.
> 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.
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.
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.
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.
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.
But I wouldn't want to be in a place where there was just good at coding was the end of my growth.
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"
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.
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.
The further I get up the ladder, the more I realize that everyone is faking it.
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”.
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.
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.
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.
Sure, every senior dev can code. But 'Senior' isn't about being the best coder... it is about being helpful with the bigger picture.
This is getting totally out of hand. What virtue, exactly, is purportedly being signaled? Love? Hope? Faith? Prudence? Temperance? Courage? Justice? Charity? Fortitude?
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.
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.
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.
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.
Funny, because 2-3 years seems to be on the low end for "junior".
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.
For example, achievements that would get a junior engineer promoted are expected to be the normal level of achievement for senior engineers.
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.
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.
‘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.
It was fun.
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 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..
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.
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.
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.
Companies that don't have a Senior Engineer title tend to promote good engineers into management roles where they are often quite mediocre.
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 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.
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.
I don’t think that’s either good or bad. Just the way it is.