> been a professional engineer for 6 years
Man, the software world is just weird.
> been a professional engineer for 6 years
Man, the software world is just weird.
In the military 6 years is definitely considered senior and I’m sure that’s also the case in a lot of other fields.
It seems like (at least outside of the military) the duration to being senior and the importance of things not going wrong are correlated.
Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professionally was in mid-aughts, and I have zero experience with React, TypeScript and other modern staples of that area.
I'm not in the US though and also work as a contractor so it's hard to use titles like these in my daily work.
[1]: https://about.gitlab.com/handbook/total-rewards/compensation...
But in software (and perhaps all knowledge work) many many times its the lowest ladder employees who are closest to the actual problem space. They are the ones dealing with the hacked up code base from 8 years ago, the indecipherable comments, the untested code that is critical to the business.
The job of the more senior people is not to command and control those employees, but to empower them. Bringing breadth of experience, or in depth expertise that is not specific to the problem at hand to help them make a decision.
Sorry, rant over.
That’s why one of the most important differences between a more senior engineer and a more junior one is the ability to mentor.
Title inflation dictates that there is and inevitably will be.
If you’re senior after six years, and you’re staff after 12 then eventually people will be staff after 7 years and there will be a new title above that which takes 12 years to get (principle?).
I haven’t seen a junior in 10 years, I haven’t seen an intern in longer. People seem to come out of school into “mid” level roles - which means the mid levels are actually entry levels and the titles shift down.
Only in industries where software development is not a primary business; beyond Senior there's titles like Lead, Staff, Principal, Distinguished and Fellow SWE, or branching off, things like architect.
Anyway, senior engineer is less about what languages do you know and more about making informed technology decisions, maintaining quality, managing and training less experienced people, etc. It's also - IMO - not down to years of experience, because you can have 25 years of experience but be stuck at a certain level or stuck in a certain technology.
(And how lucky they are at getting promoted withing that company)
Staff, senior staff, principle, distinguished, architect, etc?
Don't see how that's possible. I wouldn't even think 50% of what makes anyone a good Java developer is due to anything Java-specific. And you'll undoubtedly pick up Java-specific knowledge faster than the graduate is likely to.
Also the quote is 'professional', so although it's probably not the case, it doesn't preclude spending your 6 years in 'graduate school' beforehand anyway.
You don’t have to do a postdoc.
I could even see that going faster than 5 years, especially in a startup. For example, say one of your early hires is fresh out of school, but really curious and learning fast, already did some open source, learns from mentoring/osmosis, takes easily to a team sensibility, and has to tackle a lot of things like is the norm in a startup. Within a couple years, as the startup is starting to think about titles more, they might be a battle-scarred veteran with firsthand experience and maturity beyond their years. (Or, even if not everything is yet the complete senior package -- such as maybe they've only worked on one system and team, and could've overlearned from limited data points -- you want to acknowledge the value of their contributions, as well as their institutional memory and cultural role. So maybe help them level up any aspect they haven't yet had a chance to.)
(BTW, I avoid the term "professional engineer" when talking about software, because I've heard it have special meaning in the more regulated, traditional engineering disciplines.)
It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends.
There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems and were never around to see your bad decisions bear bad fruit.
However, the opposite does not hold. It doesn't matter how intelligent you are, you can't short circuit repeated experience and the mix of breadth and depth required. People want to. I wanted to. But I didn't: all I became was an overbearing mid who had the rhetoric (and the OSS contributions!) to convince others I knew what I was doing. There is absolutely no comparison between myself in 2017 and myself in 2022, but we both have a job title of "Senior Engineer".
In fact, I think that in the long term the trend is for the senior bar to get _higher_. This is pushed by two things: firstly, that the technical domain gets harder, software becomes more abstract, our expectation of engineers increases particularly in "left shifted" environments where every IC must do everything from frontend to microservices to infra to security to testing.
The second force is demographic: as IC salaries have increased, there has been less pressure for senior engineers to exit in favour of the management track. That means more experienced engineers on average. Industry needs a way to describe these practitioners, beyond "very senior", and overall the range of skills of ICs will widen. Under those conditions the definition of senior engineer gets more exclusive, not less.
Are there those who are masters of their craft who call themselves a senior, of course.
I'm trying to reconcile meaningful titles with current industry norms.
I'm open to other schemes, but, FWIW, this is my current rough idea:
* First is some kind of new college grad. Some of whom would object to Junior in their title, and I think Technician sends the wrong message about near-term goals, so I'd just call it plain Software Engineer.
* After maybe at 1 or 2 years, they've been through some projects, and they know a lot of the mechanics (big contrast to a new-grad who learns as they unlearn what they got from bloggers). You want to acknowledge that, so maybe it's Software Engineer II.
* At some point, maybe it's 5 great years in, they've seen a lot of stuff, and gotten wisdom and insight, and Senior sounds about right and conventional. This could be a plateau title that someone has for a decade, even as their TC increases quite a bit.
* Staff and Principal engineer roles transcend project teams (more than Seniors do). Large companies will each have their own definitions, and there might also be unwritten meaning. (At my first hardcore software engineering employer, there was no Staff, and only a tiny percentage ever made Principal. By the time I made Senior, the VP asked me where I saw myself in 5 years, and I said Principal... He gently set expectations that that's pretty ambitious, only a few people ever do it, and 5 years would be very fast. Correct on all points, and now I think I have a better idea of how much more the Principals knew that I didn't even know were things to be learned.)
There's definitely inflection points at years of experience:
0: Good enough to be hired
1-3: Solid team contributor
3-5: Best IC on a team
5-8: Lead a project/team
8+: Lead multiple projects
Then from there it's increasing complexity of teachnical problems and project size.
If you're insisting that senior applies only to the last level what do you call all those steps between 0 and 8.
I do agree that certain habits or experience from working for additional years might be missing, but as the first engineer of a codebase, IMO, there will always be something to learn from them. Which makes the article credible enough to warrant a read.
IMO "senior" is a function of behavior not time. At FAANG, levels are formally defined by traits. For example, a senior engineer can plan and lead 6-12 month long projects, delegating some parts of the implementation to others where appropriate. I personally was fulfilling this definition at 25 and I know several dozen others in similar situations.
But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of experience to reach the near top of the software craft.
It’s just as stupid but there is a different reason for it.
A senior judge is also quite literally a semi-retirement role. You take on reduced workload.
> But what if you were outside the industry and heard that term?
"Senior Associates" in the legal profession are junior/mid roles, similarly, senior account managers etc. aren't particularly senior in most places. In white collar roles, a "senior" is really just a distinction of independence and reliability.
I think you confused the JS ecosystem with the C# one.
What do you mean?
Although I don't see why you're bashing C#. Despite the .NET Framework > .NET Core > .NET transitions, it's not really that different. There's a ton of new functionality and ways to do things, but for the most part the old ways still work too.