Hacker News Reader

Comment by starfleet_bop | Hacker News Reader

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.

View on HN

"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.

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

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?

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.

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.

> 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.

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.

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.

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.

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.

>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

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.

Reply on news.ycombinator.com