Things I Learned to Become a Senior Software Engineer | Hacker News Reader

Things I Learned to Become a Senior Software Engineer

neilkakkar.com

144 pointsjanvdberg120 comments

It seems millennial achievement medals have now become job titles. Two years to become a senior engineer out of college is a joke. You only just know how to work in a general sense in that time frame, domain expertise comes much later. After a University degree, you only really know what page in your textbook to turn to when you recognise a problem. I come from a mechanical engineering background and it probably takes between 6-8 years to become a senior engineer, and it genuinely takes that long to learn enough so that you don’t harm someone with your shitty design.

"Senior" at Bloomberg certainly used to be (when I worked there) a title used to distinguish between [just-graduated] hires and [everyone else]. The cut-off was explicitly two-years out of university. It had very little to do with true real seniority within the R&D tech organisation/hierarchy.

I'd guess at the poster not quite realising this themselves. It certainly used to be the case that the many fresh new graduates we recruited annually took quite some time to learn how much they didn't know.

Twenty years ago I was promoted to "senior" three months out of university, for the adhoc purpose of improving the number of senior developers on our pitch to clients.

On the other hand, that was the dotcom era. The number of people writing software simply exploded, as did the available technologies. The entire traditional way of doing things was simply obsoleted, multiple times over. A 21 year old Finnish student had released an operating system that contravened the textbooks and went on to change the world. A 21 year old dropout invented the entire genre of 3D video games. The largest software company in the world was run by a Harvard dropout. It was really impossible to overstate the extent to which credentials were meaningless and results were everything in the dotcom era. And that still affects the culture today.

> between 6-8 years to become a senior engineer

If you follow that timeline, there would be plenty of people who were millionaires and on their second or third startup board before reaching "senior".

Now, not everybody is a Gates or a Carmack or a Torvalds, although the industry has not quite adapted to this fact and still tries to hire as if they were. But we have to recognise that the timescales are simply very different from mechanical engineering, and that the industry is still very much being disrupted from below.

Oh, and none of those prodigies are millenials.

>If you follow that timeline, there would be plenty of people who were millionaires and on their second or third startup board before reaching "senior".

What does being a successful entrepreneur have to do with being a senior engineer?

Well indeed. If you can write an app well enough to earn a million dollars, what use do you have for other people's opinion of your seniority?

I guess, although the arrow of time moving as it does I probably wouldn't want Jerry Yang developing my web app despite the great success with the last one he made.

Senior implies quality, making money off of software often doesn't require quality.

I agree 100% with you

Have worked as both PM and developer and now run my own very small software company

A) two years senior engineer is like one of those consulting companies where everyone in 2 years becomes DIRECTOR

B) In two years most new programmers have not even gotten their heads out of their asses

C) You should refer to Outliers

10,000 hours to master a task

And to that add

10,000 hours to make your first masterpiece

D) Even if you have managed to get 10,000+ hours of coding experience in high school and college and somehow become a very good programmer (which less than 3% of CS grads do)

it will still take you 6 to 10 years to get another 10,000 hours of working on masterpieces and making really good software that you can ship and make money from

E) a title like 'Senior Software Engineer' should be reserved for someone who has MADE and SHIPPED and GENERATED MONEY from a very good piece of software or some software product

F) Personally, I would think any company handing out Senior Software Engineer titles after 2 years is a joke

Between all the places my friends and college mates and I have worked (Microsoft, Google, Amazon, Facebook, Oracle, etc. etc) I can't think of any place that handed out Senior Software Engineer like it was candy

Even very, very good programmers had to EARN IT

E) a title like 'Senior Software Engineer' should be reserved for someone who has MADE and SHIPPED and GENERATED MONEY

Not all software is made to make money.

There is a more convincing argument that saving time is a motivator in a significant proportion of software either directly or indirectly; but honestly that ugly assumption of monetary motivation in everything of value is quite alienating to some of us - even in something as benign (?) as a discussion here.

Time is money

That saying is why I suggested time as a more useful (but still limited) alternative.

How long are we going to hold onto this silly 10,000 hours thing? Mastery, and high levels of skill, are a combination of inherent talent + explicit effort (not passive time) + quality of experience. I have seen 15 year experienced engineers who are utterly useless, and 2 year engineers who are incredible in everything they do.

Your description of a senior engineer is not a job one person should be doing. If you’re trying to get a senior engineer to figure out how to make something, support it, deploy it, and monetize it, you’re going to get half assed work on every front.

Beyond all that, the ranking of senior should be more company scale specific. A senior engineer at FAANG needs to be able to scale infinity and build things that never break. A senior engineer at a 30 person company needs to build quickly and AB test features rapidly. Ultimately, “software engineer” is far too broad. It doesn’t really embed much knowledge beyond “knows how to code”.

>How long are we going to hold onto this silly 10,000 hours thing?

Easy - until some other metric comes along to reliably replace it

It's a useful rule-of-thumb

It's not an absolute, and, had you bothered to read Outliers, you'd know that

But it's more fun to sit back and armchair quarterback others via anecdote, right?

didn't yahoo have an awful lot of directors? (or was it vps?)

I think people forget just how new the web industry is. The web itself has literally only existed since 1992. It's only been commercially viable to charge people for websites since around 1995. Web development in the modern 'building apps that are accessed in a browser' sense has only been done for about 20 years. If you're talking about 'single page apps' that drops to about 10 years.

Someone with 2 years experience in web development has been working in the industry for 10% of the entire time the industry has existed. If they've got a 3 year degree and a few years building things before that as a kid, they might have been making web stuff for 50% of the time anyone in the industry has been working in it.

"Time served" as a measure of experience doesn't really work in an industry that's as new as the web, nor does it work in an industry where the barrier to making a website is knowing how to open Notepad.exe.

Really good people could definitely make senior level by the time they've been working professionally for 2 years.

From a technical standpoint, I agree that good people can reach the bar of senior engineer very quickly - potentially right out of school.

However, there are aspects of a senior engineer role that are not commonly learned in school or by hacking on hobby projects. How do you effectively lead a project? How do you balance requirements? How do you say no to stakeholders? How do you balance time vs quality?

All engineers need to be good at the technical side of the job. But as you rise in seniority, the job includes more and more judgement calls. Those judgement calls require years of experience.

How do you effectively lead a project? How do you balance requirements? How do you say no to stakeholders? How do you balance time vs quality?

Moving someone up to a senior role is giving them the opportunity to take on more responsibility and develop their skills. Very few people are promoted to a senior role already knowing how to manage a team well or how to balance requirements. The expectation is that they've shown an aptitude and potential in a mid-level role, and that they'll learn those skills after they're promoted in to the new role.

Promoting someone to senior isn't a reward for already doing everything a senior does. If you treat people that way, and give mid-level people the responsibilities of senior roles without the pay or title, then they will leave very quickly to get jobs where they do the work of a senior with the pay and title of a senior.

> Very few people are promoted to a senior role already knowing how to manage a team well or how to balance requirements.

There’s more to it than that. If you’ve had a chance to work under someone who knows how to do the job (or someone who doesn’t, but you can see other groups that work well) then you have some idea how to do the job.

It’s similar to programming, or any other job: you write good code and bad, and learn which causes more problems; you read good code and bad and learn from it which of your own practices are good and which are not.

You don’t understand what was in your textbook until you see it in the real world. All that takes time.

Not only this, but there's a distinct difference between senior technically and senior managerially

A "senior" doesn't have to be able to lead a team (though they should probably learn)

If they're going the team-lead path, that's great

But it's not (and never should be) a "requirement" to be "senior"

Do you think that could be solved by disconnecting salary from title?

A 10x junior engineer should be paid a lot - more than most senior engineers if everything is fair. But the rockstar junior engineer would still benefit from mentorship and someone to help them avoid some of the mistakes that we have all made.

If you look at Google, there are terminal levels that employees can reach and stay. That doesn't mean that there is a mass exodus of talent because employees want an inflated level somewhere else. They are well compensated for their work - they just don't get a new level every couple years.

It's not a matter of skill but of experience. An engineer after a few years has usually been exposed to a lot of the countless failures projects/teams/management/companies that can happen, and so hopefully will have a much better idea of how to increase the chances of success.

The web didn't pop into existence out of the void. There were various substrate and precursor technologies that existed before the web was invented, and when the web was new, you'd expect engineers to know and understand these technologies as well.

Pure technical expertise alone is not enough to make you senior IMO, I would say it's your capacity to successfully conduct projects in many political or technical contexts, given the constraints (time, money, etc...). Also understand and deliver business value, and talk with decision makers. At least that's the biggest difference between 20 and 30 years old me.

I don't see what this has to do with millennials. Leaving aside that "achievement medals" were generally made for the sake of the parents and not the child, it certainly wasn't millennials who came up with, say, the idea that banks should have thousands of vice presidents.

In any case, it is absolutely possible to have significant domain expertise in software engineering two years out of school. When you're seeing results of the things you build within minutes, you can pick up experience quickly. I agree that you still have a lot to learn, and I did, but I was meaningfully capable of providing technical leadership two years out of school.

Came to also share my surprise of reading stuff starting with the back in the days when I was just a junior 20 months ago. Even if accurate, TBH I stopped reading after that

Agree. Nothing about this reads senior engineer. The writing is quite lacking. The material isn't technical, or engineering oriented. It's essentially self promotion.

Honestly I've got ten years of experience by now but I have no clue what "level" of seniority I would be at, because I've never worked at a company that had "levels"; you had roles like front/back-end developer, maybe architect, but not really any formal gradations in between. Pay differences maybe, and skill levels, but those were never formalized.

Is there an online test or something where you can "gauge" what tier you'd end up in a bigger company that has tiers like that? I'm not convinced I'd end up anywhere at the top because I lack things like knowledge about compilers or algorithms, things I just don't need to know in my day job.

Large tech companies usually have a career ladder that describes the expectations that come with a particular job level / title. Most aren't published externally but they look something like this example: https://www.ctl.io/developers/blog/post/career-path-of-a-pro...

[EDIT] Here's a slightly more detailed example from Thumbtack: https://docs.google.com/spreadsheets/d/15ACBs-crUHnqf1wANUQw... They can get much more complex than this though at the really big tech companies.

Titles don't actually translate across companies well, that is more true across industries. Also grads will see their peers get a new title at some other company 2 years after college. A new title with a good raise at another company is definitely a reason enough to leave the current one. With avg. stay of 2-3 years at a company it makes sense for a company to try to retain sw talent with a title change whether or not it changes the meaning of work.

The definition of “senior” is vague and subjective. When you try to say objective things such as “6-8 years to become senior”, that’s meaningless because “senior” is undefined.

Obviously becoming a senior engineer shouldn’t be based on tenure alone. In my experience, 6-8 years is roughly how long it takes to acquire enough skills, both technical, people, business, and safety in order to become responsible for a piece of work.

Being a senior engineer at Facebook where your responsible for making sure Cat memes load more quickly, and a senior engineer for an industrial control systems company making weapons guidance systems are totally different levels of responsibility. But, job titles are often transferable and should be better regulated across the industry.

>Being a senior engineer at Facebook where your responsible for making sure Cat memes load more quickly,

this strikes me as an unnecessarily rude dismissal of the difficulty of engineering at scale

this might sound crazy, but some people are actually just good at their jobs and will, naturally, progress quicker than others.

I interpreted that more as a difference in the potential problems you may cause rather than the skills required, as GP referred to "responsibility".

If FB goes down, people waste less time online[0], if a guidance system fails people may die.

[0] yes, of course there are people whose livelihood depends on cat memes, but I'm making a generic example.

> If FB goes down, people waste less time online, if a guidance system fails people may die.

Goes down yes, but what about a data breach? What if, for example, the location of a woman is mistakenly exposed to a abusive partner?

In my view the distinction between a senior software engineer and not is the ability to see how both human and software systems interact and find failure modes that others may miss.

You know you're in a bad spot when you start arguing that a website has as much potential for bad results as a weapons system.

by definition it's not true, and any sequence of thoughts that lead you to that conclusion are wrong, period.

> Being a senior engineer at Facebook where your responsible for making sure Cat memes load more quickly

Hey now, don’t underestimate the technical challenges inherent in weaponizing misinformation at scale.

yeah the fb engineer likely makes 3x as much and went to a better university and is generally smarter

And in my experience it takes two, if you're good at what you do. You probably get more responsibility for systems that deeply affect people's lives and the world around us as a new grad at Facebook than as a mechanical engineer, which is probably part of it. And you probably do pick up more skills about building reliable systems, threat modeling, product planning, etc., all of which would be transferrable to other types of engineering. It's unfair that people working on a global CDN can see the results of their work in seconds and people working on a military weapons contract see the results of their work in years, but it's true.

So I very much agree with the sentiment I started writing a similar comment, but if you scroll down to the very last sentence (it's a bullet point) of the article it says that the author is not a senior engineer.

Oh boo boo. And who gave those millennials those achievement medals? Their boomer and gen x parents. Stop blaming young people for problems that existed before they were born.

Not if someone is striving every day to become better, observe, learn, test, and adapt. For someone who procrastinates a lot and does not proactively look to improve, it might take 6-8 years!

I don't know if this comment is serious, but I'd suggest you explore the idea that you don't know, what you don't know. With a few years of experience, you can feel comfortable in a technology stack and seen and learnt from a few mistakes. You may know the names of other areas, and played around with them a bit, but you won't understand their pitfalls. This is not enough to make decisions. Software is not easy, it's far too easy to make reasonable design choices, that turn out in the long term to be poor. These can cripple large scale systems.

There is so much that you can't learn from books. Reading Mythical Man Month does not make you Fred Brooks, reading Shoe Dog does not make you Phil Knight, nor does reading a medium article on event driven systems make you ready to implement one.

Imagine that the college of surgery acted in the same way, a surgical trainee who has worked for a few years and reads a lot may feel comfortable taking the lead in a surgery, but will be out of their depth the moment things deviate from normal. I spoke to a surgeon about this once, and he described how he taught a particular procedure. At one point he has his student reach in to the body, with the explaination that 'it should feel like this'. No book can substitute that experience.

What you say is true. Perhaps, a distinction ought to be made between mere mortals like us, and the obsessed ones. In our era where information is more easily available than food, and where experienced people willing to help, are just as reachable, I think for someone who dedicates the time towards mastery, 2 years will take him/her very far.

I say this as someone who started learning to program on his own at age 8, and is now 37:

> I think for someone who dedicates the time towards mastery, 2 years will take him/her very far.

You might get very good at a particular niche in 2 years. You will not have learned the lessons you learn when you go back to a five year old project yet and make changes. You will not have the breadth of experience from having worked intimately with dozens of teams in different languages, cultural expectations, and business domains.

Honestly, the more I learn, the more I know I don’t know. As an example, last year I had an opportunity to work on robotic control systems. I dusted off my calculus and linear algebra skills from way back, implemented calculations that ran in under 1ms, and has a ton of fun doing it. Could I have explained a Jacobian before starting that project? Not likely! Do I use it in other stuff now too? Definitely.

> Two years to become a senior engineer out of college is a joke.

Sure

> After a University degree, you only really know what page in your textbook to turn to when you recognise a problem.

No.

My first job during college was to create an iOS app for a researcher (an extensive multimedia questionnaire). What I did: take Hegarthy's course, and understand it. After that, I simply could create the app by thinking logically. I didn't refer back to the course while I created the app.

My first job out of college was upgrading some Java CRUD app. I had the fortune of teaching at a coding bootcamp (as I self-taught NodeJS and then taught it). That NodeJS experience, including with having familiarity with the Java syntax was enough to edit files for a Spring Boot application. Simply by reading the code, I understood what happened and how they wanted me to design things.

No textbook required.

> don’t harm someone with your shitty design.

It's possible that might've happened.

You may have had the ability to create a fairly simple app or add to an existing one with low stakes / impact. But, it takes time to be able to quickly reason from a fundamental, first principles levels in order to engineer robust solutions to problems.

On a side note, I don’t agree with bootcamps as they don’t teach the core principles of computer engineering and software design. Coding is just a skill, and you need some fundamental knowledge behind it in order to execute it safely and robustly.

You're making a lot of assumptions about my situation that you can't backup with evidence. It might be true. It might not be. But you seem to make a strong stance for that I worked on apps with low stakes/impact and that they were fairly simple. You don't know that, so why paint that view so strongly?

> On a side note, I don’t agree with bootcamps as they don’t teach the core principles of computer engineering and software design.

I did both. I studied CS and happened to work as a teacher at a coding bootcamp while studying CS.

> Coding is just a skill, and you need some fundamental knowledge behind it in order to execute it safely and robustly.

Emphasis mine.

I disagree with this. I've seen many experienced software engineers knowing nothing about how to hack (important for safe code execution), I've had a couple of courses in it and did some hackthebox.eu after that. So I know as much about hacking as I know about software engineering, I'm a junior in both cases. Nevertheless, I am the one that finds major security vulnerabilities in the code of the company I work for.

A lot of security issues isn't fundamental as the "fundamentals" are things like: "look for configuration errors" or "look for hardware bugs that hardware vendors haven't looked deeply enough yet" or "look for a place where humans are careless" (e.g. the suidbash vulnerability is an example of the last one). That's a lot fuzzier and vague than CS fundamentals.

To start with, "Senior" and related titles basically mean a person who doesn't need much hand-holding. This might be related to time spent, but often you find there's a lot of variation.

People I consider senior software engineers have a can-do-anything vibe about them. They have a wide range of skills in the field, and have that T-shaped experience profile: there's some area they seem to know everything about, and then they somehow are able to say something sensible about a whole lot of other areas. For instance I worked with a guy who wrote financial exchanges but could also write a modern front-end, understood how kubernetes worked, and knew a fair bit about databases. You couldn't throw out a term that he couldn't place (X is a language / framework / pattern / OSS project), and you couldn't come up with a problem that he didn't know the closest well-known adjacency for.

That's a vague outline of what I think a senior dev is.

To get there is a long story. I think you need the good fortune of not being siloed in something very specific or superficial. That might even include having the "good fortune" of being forced to change jobs a few times. You also need some luck in your personal life to be able to explore a bunch of stuff in your own time, plus some funds (probably less relevant today where everything is an online service).

My experience is people in "senior" roles are more often than not people who pushed to be put in those roles regardless of how much experience they may or may not have. I know people placed in "senior" roles at 19-21yrs old. I'm not saying age is a qualifier but in this case it was clear they didn't have any special skills. But once they were given the role it carried them through their career. With the title on their resume they continually got hired and higher and higher levels.

> To start with, "Senior" and related titles basically mean a person who doesn't need much hand-holding.

I'd call this "not junior". To me, "senior" would be the person leading a small multi-person effort or doing the hand-holding of junior engineers.

Usually leading engineer is called "Lead Engineer", which is step over Senior.

Of a small group? I'd ordinarily expect a "lead engineer" title to be overseeing 6-20 people.

Not op, but I’d call what they’re referring to as a team lead. Usually a team lead manages 3-6 people, isn’t a manager, but is a senior engineer and has technical leadership abilities.

I'm more familiar with EE levels. From OPM: https://www.opm.gov/policy-data-oversight/classification-qua...

and if you can find: POSITION CLASSIFICATION STANDARD FOR ELECTRICAL ENGINEERING SERIES, GS-0850 ELECTRONICS ENGINEERING SERIES, GS-0855 TS-3 February 1971 It has good information on what level engineers are working.

I think you have the correct frame of reference, senior level positions are those who are used to handling projects/questions without guidance from others (although most senior folks are willing to ask questions to learn)

> People I consider senior software engineers have a can-do-anything vibe about them.

I feel I can do anything as well, because if I can't then I will simply find a way to learn it, because to me it's not a question of whether I'm capable of learning it but how fast I'm capable of learning it. So I'd be careful with that vibe as a heuristic ;-)

In my experience, it's more a mark of "do do" than "can do".

i.e. how far along are you in the progression of... - being given clearly defined tasks - self-guided work on feature level - self-guided work on project level - self-guided work on team level - self-guided work across teams etc.

> To start with, "Senior" and related titles basically mean a person who doesn't need much hand-holding.

This is my definition. Can I assign the PROBLEM, "important customer ABC has some kind of weird bug, talk to Nav in Tech Support" and know that problem is now off my plate. They'll usually solve it or come back with a hot fix recommendation. Worse case, they come back with a "we can't figure it out, we need more eyes on this".

The important part is this: the problem is now something I don't need to worry about.

If I need to follow up, they're not a senior developer. They're a junior with skills.

It’s not just knowing how to do a bunch of things. No one can do everything. It’s the attitude and meta-skills that enable picking up the next new thing.

Same thing, isn't it? At the end of the day the guy who can do anything you ask him to is going to do it by learning, not by knowing already.

While it’s not impossible. I find it hard to believe anyone could become senior (in terms of actual skill) in two years.

It's kinda hard to be one when you've never had to maintain the monstrosity you've built for more than a few months. All the hard lessons are learned 5 years down the line when the wrong decisions really hurt you.

You can maintain other people's monstrosities and quickly learn the lessons. There's a couple of folks at work who joined straight out of college a few years back and ended up with ownership of a terribly-designed production system that everyone else depends on, and they've been doing a solid job of switching it over to a reasonable architecture while it's running. I don't know what title they have but I'd certainly trust them with complex systems more than the people who built the original mess. Every poor decision, every overconfident choice of shiny new database, every weird layer on top because they wanted something expedient, every ill-advised API promise, etc. has hurt this new team, and the original builders for the most part have gone on to other employers.

Meanwhile, you can also absolutely spend five years not working on anything that needs to scale (by being at a company/team that can't execute, by building prototypes instead of products, etc.) and not have a sense of how to do better.

In my (extremely not senior) view, maintaining other people's monstrosities doesn't teach the right lesson, because there are many ways to get things wrong, but fewer ways to get things right. Previously, maintaining someone else's monstrosity taught me to avoid their specific mistakes, but not those classes of mistakes. I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings. Better to learn how to reason correctly about these things, and that probably doesn't happen until you take seriously the cost of maintenance, which really only comes once you've spent enough time in those trenches, having dug them yourself.

> I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings.

That just means you weren't valuing the right things.

At the end of the day, that's what it's about. It's not about "technique A should have been used instead of technique B", it's more about what you value. It matters because those values will inform both your decisions and your actions.

For example, someone who values performance will not write slow code. Someone who values productivity will write slow code. Someone who values stability may or may not write slow code and may or may not be productive, but their systems won't arbitrarily go down.

Everything thinks the crap they inherit is terrible. Everyone thinks they can rebuild it in a far better way. Everyone then passes their project on to someone else, who thinks the crap they inherit is terrible.

I agree, and this is why I mentor my engineers to replace the phrase technical debt with specific qualities that are impacted by technical choices:

* Resistant to future change

* Won’t scale past x units

* Prone to operational issues

* Exposes us to liability or compliance risk

* Increases ongoing maintenance costs

Any large initiative to replace "crap" should map to specific product quality attributes that stakeholders and leadership buy in to, and ultimately be justifiable back to COGS or churn mitigation. In this way, objectively, a system can be $10M better because it e.g. closes $10M in customer tickets.

Oh, I like this one. I’ll be borrowing it for future use.

This is why any of the "ilities" is a red flag for me. Don't tell me it isn't scalable, make it concrete. Tell me what specific numbers we're supposed to meet. Don't tell me it isn't readable, tell me specifically what the problem is.

I can't make any judgement on the specific case you're describing, but I've seen this general scenario play out a few cycles in my career.

My guess is that they overcorrect on the previous system designers mistakes, because they too have only had that one experience and this is their first time building a new one.

And the cycle repeats in another 5 years when a new group of fresh grads have to take over/rebuild the current new system.

I hate being ageist in any direction, but experience actually do take time, and only older people have been younger, never the reverse. The hard part is recognizing what is unique to a generation and what is commonality.

Or you can tell me I was wrong in 10 years.

No one knows what the skill threshold is anyway, so it's all made up depending on who you can convince.

This is a very subjective question. I think a senior engineer is an engineer who can develop features without hand-holding. The technical leader should be able to say, "Develop feature X. These are the requirements." and then not worry.

But what "senior engineer" means varies from company to company. So it becomes a loose term.

> This is a very subjective question. I think a senior engineer is an engineer who can develop features without hand-holding. The technical leader should be able to say, "Develop feature X. These are the requirements." and then not worry.

In pretty much all companies those were just called "software engineers". Seniority requires decision making and longterm leadership skills, not just implementation work.

By that measure we have tons of senior engineers, but the system that is built is a monstrosity.

What I want out of a senior engineer is dedication to a coherent whole.

A manager gave him the "senior" title. Where I am, "senior" means "experienced". When you need a senior developer in a team, means you need someone that went through many projects and know the errors and mistakes a team can make.

Building mental models is great, but you need to have used a few times in different context, to really appreciate when and how they were the most appropriate.

The experience of handling multi-years projects (and getting back to them after a few years too) has no equivalent.

You can read as much as you like, nothing beats experience, which you will get after years and years in the job.

There are a number of commenters here getting hung up on what is or is not expected of a “senior” employee, which ignores the likely explanation that “senior” is something that costs a company exactly as much or as little money as they want it to. Think of it like “air miles” or “rewards points”. The hiring market has been extremely tight in recent years, and so it’s natural to see companies leverage job titles as part of competing for employees. (You might hear managers say “we’re just not getting a high enough quality of candidates for this role”, and an easy thing to do is to increase the job title. Increasing the salary and benefits is much harder since it requires justifying more budget.)

True, the employee can now leverage the job title for more compensation, with their current and potential employers, but the onus is on the employee to negotiate, and in the meantime the employer gets the benefits. (Note that “benefits” does not mean that the employee suddenly becomes better than they are, it means that a known-quantity employee continues to do satisfactory work for the company for a time, at an acceptable price.)

There is a shocking amount of ad hominem and focus on the years of experience in this article. Are people actually reading the article? Perhaps surprisingly, it's really fucking good. I'm absolutely planning to share this with junior devs that I work with.

Author may not realize how much more there is to learn than he already knows, but we all kind of have that problem, just at different scales, am I right? He's doing all the right things, learning the right lessons, and is on track to be senior whether he has that title at work or not.

Thank you, darkerside!

One meta-goal of the post was to figure out how I can grow further. Are there things on top of your mind which I should be exploring next?

One thing I'd expect to see more of in this type of article would be understanding the business domain. It sounds like you understand the value of doing so from your section on leaning what others around you are doing. But I think over time, you'll see that learning those specific business nuances is what separates the promising engineer from the seasoned veteran who hears a business problem and already knows the 4 ways it's been attempted to be solved and why they didn't work. And importantly, still has the optimism to try again in a different way! I recognize every organization is different so YMMV.

Rereading my post it may have came off as a bit of a backhanded compliment and wasn't intended as such. Terrific post. I think it will help a lot of people.

This person has been promote one level up from the new grad level. Not exactly what I would describe as senior

It's a good start but still some way to "Senior". Keep up the good work.

Now, it is easy to start giving "tips", but I think nothing replace good old learning on your own mistakes. Thus, the only tip I can give is to be reflective and honest with yourself to be able to learn and grow.

I'll be honest, these kind of "thinkpieces" are usually full of generic bullshit but this one was actually interesting. So if you're like me, don't let the title put you off and read it.

I live in flyover country, so adjust these numbers for your locale.

There are "seniors" who make $60,000 per year. No joke. And there are seniors who make $140,000 per year (in a rather low cost area.)

The PHBs have figured out that we are vain and can be lured by shiny titles. We shouldn't go out of our way to make it easier on them.

Software engineer is a working class profession. Lusting after title plumage hurts us.

I like this take. Personally, I know that I'd _for sure_ take a job with a greater amount of pay, benefits, and work-life balance if I was going to be "down-leveled". Heck, if I'm down-leveled and being paid more, that likely means I'm working with more skilled engineers.

I'm disagreeing with this statement while liking the general direction and content of it!

"There was only so much I could do to improve my coding skills. Most blogs epousing techniques to write cleaner code, repeating yourself, not repeating yourself, etc. are micro-optimisations. Almost none of them would make me instantly impactful."

I do expect a Senior Software Engineer to be good in programming. Because mastering programming is, what you do due working with it every day. The basics should just be.

Doesn't matter how impactful those are. Your role is to sure look left and right, but the road you are on is becoming an expert in what you are doing.

And generally speaking about the Senior title: I think from reading it, he does look in the right directions and it could be that he is already there but for me, Seniority become a thing not after understanding all of that stuff but actually incorporating it in a way that it became second nature and honestly, it took me years and a handful of core experiences along the way. But who am i to determine his seniority through a blog? :)

I'm curious what's it like to work for Bloomberg in London? Can anyone share some info or experience? (I know Glassdoor exists, I'm asking for a more personal overview)

It's been a while since I worked at Bloomberg, but certainly back then, anyone with 2+ years experience was designated a "Senior" hire.

It was (is?) more about distinguishing fresh grads from other hires, and much less about significant experience or seniority within the tech ("R&D") organisation.

> Figuring out how to become a force multiplier sounds more valuable to me than a 10x developer.

I'm always astounded by what people imagine a 10x developer is, especially some one who calls themselves a senior developer.

Hint, they aren't a lone wolf who writes 10 times as much code as the rest of the team, doesn't deign to sit in scrum planning sessions and creates chaos with every pull request they self approve. Maybe those people CALL themselves a 10x developer ...

A 10x developer IS a force multiplier. Every 10x developer I've worked with wrote easy to use APIs and Frameworks that made every other developer on the team much more productive. A 10x developer is a senior developer on steroids; they do everything this author thinks a senior developer does and more.

To add to your point: the "lone wolf that writes 10x more code" is not someone you want on your team because they're not a multiplier in any sense other than simply "writing 10x more code". They're actively detrimental.

I have a draft blog article called "The Almost 10x Developer" because I have seen exactly this soooooo many times.

I know a 500x developer. He is not proud, because he knows somebody else who codes 10x faster. This other person wears out several keyboards before his CPU is obsolete.

If programming were really engineering, you would need 20 years to be Senior. A Senior Engineer keeps the organization from making disastrous mistakes and unnecessarily complicated designs.

Since the title was squatted, actually-senior programmers are being called Principal Engineers. Do not make the mistake of calling yourself a "Principle Engineer".

What is the definition of "Senior/Staff/Principal/No-prefix Software Engineer"? All those titles always confuse me

Junior/No-prefix: In their first job. You will routinely get promoted from junior to "normal" whilst remaining at the company.

Senior: Second or third job change.

Staff: That one person who has been at the company forever.

Principal: We're an enormous engineering org and need to have a treadmill so we don't lose our people but can't just give them payrises. Most titles also have multiple levels.

My take is that your seniority refers to how much responsibility you can bear.

If I give a solid junior a clear spec, wireframes, guidance on tools and mentorship then they should make progress according to the spec. If what I assign to a junior engineer is impossible to implement or useless to the product, that’s on me.

A senior should be able to succeed with much higher level / vaguely specified tasks. Like, here’s the client. Here’s the team. Go figure out for yourself how you can add the most value. A good senior should be able to figure out if there’s resources or skills the team is missing, and solve what needs solving in order to make the project successful. Sometimes this is non-technical - like raising issues with the client, organising to hire another UX person, etc. A senior should be resourceful.

You can frame the same thing in terms of responsibility scope. A junior is responsible for the assigned task (as the task is described). A senior/principal is responsible for the project being successful or the company’s software meeting the needs of the business.

Senior/staff/principal/etc to me mean beyond vague locations on that junior-to-senior+ engineer resourcefulness axis. I don’t think there’s any agreed upon definitions across the industry. (Though google, microsoft, etc all have their own internal working definitions)

Titles primarily exist to justify higher pay inside a team, and/or lower pay wrt to some other company.

In simple terms, Sr. usually is an understanding that you are on your own. Do not expect any one else to tell you how or what to do. Also, the ones without Sr. title may become your responsibililty.

Though debatable, it has nothing to do with your technical skill set or experience.

It's pretty arbitrary, and depends also on what you negotiate when getting hired. I've seen people that got hired as seniors that performed just as well/poorly/... (depending on your perspective) as mid-level folks.

I've also seen the title of "senior" in one organization being wildly different to a "senior" in another organization within the same company. For example, for some reason, the "API dev team" had insanely high bar whereas the "submodule X team" had seniors left and right, quality-wise nowhere near seniors from the "API dev team".

This all has led me to believe getting promoted is simply about renegotiating your salary with the company, and has very little to do with your actual skill. It has more to do with who's your direct manager, and what is your relationship with him/her.

Personal and anecdotal experience only of course.

My understanding is the following: No-prefix < Senior < Staff < Principal.

In details, I see it this way:

No-prefix: focuses on the here and now with little responsibilities about long term strategy/cooperation with other teams.

Senior: he/she can be/is a TL. Sets the direction for the team and thinks about medium/long term strategy/shape of the code base. Also, they tend to be the liaison between the team they are under and other teams, but in a tactical/ad-hoc way.

Staff: Like senior, but more on the strategic side of things (i.e. longer term planning).

Principal: Usually the TLM/uber TL for a working group (few teams). Can also be a director for a working group.

As pointed out by other replies, It is subjective and also company-dependent. In startups these levels tend to be compressed, in FAANG companies there's a distinct increase of responsibilities with each title.

Do definitions of those even exist?

I think it's up to the company whether you're Senior, Ninja, Shaman or Necromant Developer

There are no strict definitions, different companies do it differently, have different requirements and role descriptions. Usually the path is junior -> no prefix -> senior -> staff/lead -> principal (some companies have only the first 3/4, then only management above).

One good source I found is gov.uk site: https://www.gov.uk/guidance/software-developer

Variations on the perceived value of an engineer in one organization

I was a bit worried about the title saying "Senior Software Engineer" because this may trigger people.

But, surprised that all the discussions are about this, instead of the content.

That's probably because the content in this post is more about "soft skills" or what many would consider fluff.

"habits of mind", "tools of thought", "force multiplier", "superpowers" "embrace fear" etc. reads straight out from a Tim Ferris-like self-help book targetting millennials than anything a senior engineer would write.

I read your last year's post - that one was much more useful and insightful. So +1 (upvote) to more of those.

There are a bunch of topics on HN that tend to bring out the same debate again and again irregardless of the content of the link.

Hi Neil.

Appreciate the writing. I wonder if everyone is senior at Bloomberg then how does the pay raise work?

While there is much sage advice in this blog post, the topic that I appreciated most was the gotcha about neophilia.

Not only have I seen my own natural tendency to overvalue new technologies irrationally, I've seen it in most of my colleagues as well. Stepping back and carefully weighing the pros and cons of new technologies is an excellent way of preventing neophilia from moving a project in the wrong direction.

Hmm. Good read. Then I think everyone should write something about their accomplishments in their own blog like an article on how I became a tech lead and it would be mostly like, it's not fun. Being a team member was easy, you know taking up few projects which others considered hard and you know it's simple just too much action everyday. And always start a presentation saying, "it's a simple project having n,n,n,n,n things" and go slow so others would go and review all the things you did in the call itself.

But now you are working on 1 project namesake and hearing about all projects, resolving issues getting into sudden meetings and knowing requirement was understood differently and thinking about what sort of risk should be raised for this project. Then you get to a discussion with a architect on whats a microservice, he tells you a microservice can process bulk data(millions) and can run up to 20-30 mins and discussion ends like oh I was thinking microservice is like a simple unit of work and finishes off in few milliseconds to less than few seconds. Sorry I am a mainframer we caught this as it crossed our thresholds in UAT and you need to raise risk if you want this go live. (Level of risk that has good visibility to management).

Wrote an automation tool 6-7 years back for myself and let others know of it and prepared good documentation and made it part KT and now present time, saying to people not to use my tool as I am going to decommission it as there are other standard tools available to do the same thing and people pinging "please don't decom it, can you rename it and let it run, as it's easier and proven repeatedly it's error free".

Suddemly a dev contact, pings you saying I have a problem with this REXX code. You look at the code and sort of gives you thought, this comment looks like I wrote it. But I never wrote something for this application or person before and asking few more questions, you come to know that my code was used as a model in lot many places as it was easier to generate test data with it. Credit for initial work was never given few years back but looking at how many people are using gives a feeling wow.

Always seeing celebrities talking about their movies on TV. Given me the thought, how come nobody is interviewing programmers and asking what was hard for them to program and state of mind they had when programming a piece of code. What gets them to the flow state.... It would be fun to know.

To be honest what he achieved doesn't need any special tricks. You just be there do your job, and you will get it. Well actually depends on how hostile and competitive your work place is.

I guess the meaning of Senior has changed, that's fine - but what is the level beyond Senior now?

Ancient? Graybeard? Hallowed?

At Microsoft there is a guy named Peter Spiro who I really looked up to, in SQL Server. His official title is Technical Fellow but he called himself Village Elder, because he worked on it since 1.0. In his own words, his job is to float around and be available to everyone in the group.

As a serious answer: staff, principal

As a cynical answer: many companies seem to think that more that 6-7 years of engineering experience is at best a waste of money and at worst counterproductive

Obsolete and let go.

If you can make senior in 2, irrelevance should be right about 5 years in.

In the midwest it's "lead". I've also been on teams where nearly every developer is a lead, which sounds strange, but it's really just a confluence of "could this person lead a team" and pay band.

I've seen the following structure at several orgs:

engineer -> senior -> lead -> staff/principal -> distinguished

titles are arbitrary. let's not put too much stock into them.

At google and FB, senior is considered L5/E5 which requires atleast 5 yoe.

but it looks like bloomberg doesn't have a mid level and only have junior/senior.

https://www.levels.fyi/?compare=Bloomberg,Google,Facebook,Mi...

It's easy to become a senior software engineer, anyone can do it with these simple steps:

1. Open an index.html, include a javascript file and write an alert or console log.

2. Create your own company.

3. Title yourself as a senior software engineer.

Joke aside, during my career I've met several senior software engineers that are anything but and several "normal devs" that are a lot better than most people who have the senior title, even in the same organisation.

I don't think titles has anything to do with knowledge, rather it does have a lot more to do with whatever position you're given and that position could be given to you for a number of reasons. This is what has lead me to my belief that titles are unnecessary cruft that takes focus away from other more meaningful endeavors.

If I start my own company, I’ll be the Supreme and Exalted Overlord. Not something silly like a senior dev.

That is true, I think my title would be "Dream Alchemist" or something like that. ;)

Reply on news.ycombinator.com