Hacker News Reader

Comment by lumost | Hacker News Reader

So the Senior market is saturated? this is an early sign companies are getting nervous about bloat. After the '08 recession many companies rushed to ditch Architect titles as they found that the role did not serve the interests of their productive engineers or the companies higher ups. Companies that had gone heavy on such talent might find themselves stuck.

I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles.

View on HN

> I recall seeing talks on "Staff Engineer" and thinking that this was going to be the next version of "Architect". Engineers who's primary job is to write code often dislike working with people in such roles.

That depends. If they are actively involved and the architectural decisions are sound, it's fine.

If they are "drive-by architects", showing up, dropping a bunch of useless boxes they read on some book, and then leaving before the consequences of their 'architecture' are known, you are right we don't like working with them.

At many companies, however, staff engineers are still engineers.

Drive by architects don't read books. They read AWS's latest product brochure and think "yes".

I think both exist, but you're right.

The majority of Architects I've brushed against in the last decade have been exclusively an additional marketing force for AWS with very little ability to objectively reason from first principles or assist with knowledge of anything outside of the AWS ecosystem.

Totally genuine question as someone coming from a background in mechanical engineering, who now does a lot of software-y things: what do you consider to be "first principles" in computing? Are you talking about first principles in terms of project development processes (i.e how information systems evolve) or code (i.e. bits and bytes, where microservices might not be the answer because the network connections are guaranteed to have a fundamental latency that, along with the amount of data required, means you can't meet requirements because [..])?

I think I can name an example, which is how I am approaching datalisp; https://sr.ht/~ilmu/tala.saman/ the first principles bit for my context refers to: fixing a standard encoding that is sufficient for the task, determining inputs and outputs of model, setting a general guideline for expressivity of model (space of conflict-free programs), sketching interaction modes and user interfaces.

These are the first principles in question, now from there your architecture is mostly determined, you can fall back on known patterns and decades of research. The axioms are the architecture.

Thanks for the insight!

Not the parent but I will offer you my opinion after I laughed at their comment because it reminded me of many of the engineers at my current work:

"First principles" in this context is not just reaching for the nearest/newest AWS service that seems to do what you want. ie. if you want a webserver, don't just run magic lambdas that abstract everything away from you, go and provision a vps and install your dependencies on it so you fully understand and control how the stack works.

None of the 12 engineers at my current company had written a test that actually wrote rows to a database when I arrived, they didn't know how. In fact none of them knew anything about how to run our databases on their own dev machines at all, they all shared one RDS PG instance.

Again, "first principles" here is: running a process, connecting to a service, asserting the whole thing did what you expected. To do that effectively you have to actually control the whole system, and to do that you have to know how the whole system works together. A lot of developers now just delegate the provisioning and maintenance of everything to a provider, even in development setups.

This is basically the same definition I have.

First principles to me is the basic foundations of an idea.

Abstractions are used but; any given abstraction is not owned by a single vendor and are based on agreed upon standardised abstractions as they relate to to operating systems and databases etc.

Every architect i worked with read books.

The bad ones took what they read as gospel and the good ones took what they read in context.

May I also add the demi-god of arhcitecture juggernaut Martin Fowler.

My personal experience screams, ouch!

What makes a "Staff Engineer" is largely a product of an orgs engineering culture. And you may have multiple people with "staff engineer" as a job title that fulfill different roles to varying degrees.

I've found those roles to be:

* Technical Leadership (driving major technical initiatives)

* Technical Contributor (shipping stuff, with technical mastery beyond what would normally be expected from senior engineer)

* Architect (planning stuff)

* Team Management (mentorship + taking load off an engineering manager's plate if the team is big)

Biggest mistake I see orgs make when hiring staff engineers is hiring someone whose strength is in mentorship and technical contributors and decide their new role is architecture and driving major technical initiatives at a high level. Some are best "in the weeds" and others are better planners. Know their strengths!

Staff engineer is just title inflation for what used to be senior engineer. Senior engineers at most companies just means this isn’t your first job right out of college.

I have 15 yoe and have senior software engineer title so do people with 2 yrs experience.

I might be doing same thing over and over. Time to make a radical change :/.

There's also nothing wrong with plateauing for a while or even topping out, especially if you are generally happy with life and career. There's pride to be had in being a good individual contributor; not everyone needs to make it to Senior Super Special Principal :)

I keep being told I shouldn’t be writing code at my level and should be knee deep in design docs and estimations all day long. This is actually what happens but I would much prefer to be writing software and am wondering if I can even be happy in this career any longer. This industry has some real bizarre notions of career progression.

You need to write code and you need to get people around you to write better code.

That’s basically what a staff engineer does in addition to making large design decisions.

That’s my belief as well but there are managers out there that think staff engineers should never write code. It boggles my mind they think this way but many do.

Writing code means that your impact can be directly measured. Others can see quality, volume, and impact. If you stop writing code then you can't be measured. If your impact is measured by others, and you aren't bound by a team... then you can just float to where the wind is blowing. It's comparatively easy to surf in this manner.

I agree and know all this and argue it weekly, trust me. Bad management doesn’t care.

There are other organizations that are trying to deflate titles as well. (Demanding the work of a lead, staff, or principal in a Sr without the influence to do so)

What is the spread in compensation, scope of work, level of responsibility, etc.?

I have 16 yoe and have been a senior software engineer since forever.

3 jobs ago I was principal engineer, 2 jobs ago I was an engineer, now I'm a senior.

The type of work I'm doing has been the same, manage a team or more of engineers, do some architecture, some coding, help and mentor other engineers.

Pay went up.

Depends on the company. The industry can’t seem to agree on what these terms mean.

And some companies don't even have a "staff" title, just several levels of "Senior Engineer." Makes it hard when applying for a staff role at another company.

More and more senior engineers are non-coding or practically so. I see it everywhere. As industries have matured, people have matured into higher level management roles and there hasn't been enough people to replace them. There's still plenty of fresh blood, software engineering actually looks a lot like the labor shortages do in the rest of the market—there's a lack of people who actually want to do the work. Everyone wants that $150k starting comp. Everyone wants a $500k director or VP role. But there is a shortage in that $200-300K range for people who are actually going to put in hours either writing code that makes it into production, or managing junior coders and their codebases. I'm talking SV salaries here. The scale is different elsewhere, but the problem is the same.

Not for nothing, but that sounds a bit like a market peak if I've heard one. Why would the person actually doing the work settle for a mere 300k when the director/VP gets double without doing the hard work? there is a balance here - but it seems like a good time to lure engineers with real equity compensation to early stage startups.

Which industry has it different? I mean there are exceptions like sport teams but by and large this stuff happens everywhere else too.

Difference in tech has been that productivity has largely been divorced from capital, OpEx, and experience. This may be becoming less true today with large enterprises owning specific market segments through network effects... but I wouldn't bet on that quite yet in the long-term.

A doctor can't help but work at the world's best hospital, because it probably will still be the world's best hospital next year. A jet engine designer can't help but work at Boeing. A fresh college grad can start a tech business tomorrow.

Because managing people is the hard work, but it's not the grunt work. It can be emotionally exhausting.

It is much easier to teach someone how to code than to teach them how to manage. Management is two parts: (1) making sure people produce a good product for a little expenditures as possible, and (2) manage liability from employees. Particularly now, the second part is very difficult to teach.

Most people do not have great judgement when it comes to managing people and it's a really hard skill to teach. You can make someone watch training videos all day that tell them explicitly what NOT to do and they will still do exactly that. Everyone wants to believe they are good at management—very few people actually are. Most fail upwards into it.

Interesting, anecdotally at a faang adjacent company, I do not know of any Seniors who do not have code as their primary output. Even a large majority of staff actively code IME.

I'd be glad to know about these $200-300k positions. I must be applying to the wrong places - I keep hearing that my current base of 187k as a Senior SWE is out of their range.

I'm a software architect, I write code every day, I design every day, I write documents every day, and I report to the VP and CTO every day.

I have met other architects that claim they "don't code" and honesty don't understand how they can make decisions and reduce risk without that background. Most of the time I have a solution because I've been there and done that.

I view my role as one that has the expertise to bring the engineering team to the next level, because if I did all the work - it would just be one person instead of many. I constantly try to unblock, solve hard problems, and reduce entropy - and let the creativity flow to the rest of the team.

This has worked for me, as a software architect, for almost a decade.

> So the Senior market is saturated?

I am not sure I would say saturated, but yeah, the Sr. SWE market is definitely not as tight as it was a year ago for most role types. However, it does depend on qualifications and company type. Seniors for R&D positions (so, PhD with 5+ years in product-focused R&D) are still basically impossible to hire. Friends tell me that hiring seniors at mid-pay or low-pay companies is still pretty hard.

The more important dichotomy is between mid-career/late-career and junior. The entry level positions are absolutely saturated. CS programs are definitely over-producing at this point.

Might be true in the US, not what I’m seeing have seen in the UK.

Here big companies are taking kids straight out of uni and boot camping them because decent juniors are hard to find.

How easy is it to find bad juniors? I think that may be relevant for determining how saturated the field is.

CS programs are overproducing but they are overproducing the wrong skills. Most don’t have the cloud skillset or experience with IaC, they are never thought how to solve problems within distributed systems. And their idea of systems design is a Flask app talking to a MySQL database on a laptop.

It’s not the students fault, but the education system is constantly behind the times, and sometimes even teach bad engineering patterns that cause problems and create technical debt.

> It’s not their fault, but the education system is constantly behind the times.

Yes/no/maybe. The schools got pressured by the bootcamps that were teaching the "flask app talking to a mysql db" .. they simplified their classes and stop teaching some things. It sucks, the people who come out of that don't have the theory/flexiblity/skills coming out that you would expect before.

A lot of development jobs can be simplified into a web endpoint that hits a database. So that seems like a completely fair project to have students work on in an applied course.

Also, universities do offer courses in cloud computing. I was helping our interns with their cloud computing courses back in like 2016, so it's not a recent addition either.

> A lot of development jobs can be simplified into a web endpoint that hits a database.

This doesn't ring right. It might (maybe) be educational to do this, but I'd say that any "development job" that is about software development is not trivial like you say.

An "endpoint-to-database" job doesn't exist [1] - I think you're making a simplification here and the real argument is if its educational.

[1] find a job description that says REST or GQL endpoint directly to database, and doesn't have a long wishlist of other skills, experience, or design - I'll gladly take 100 of those and be on my merry way (!)

> An "endpoint-to-database" job doesn't exist [1]

This was my entire career pre-phd, and it was a pretty excellent career. Oh how the times change.

> I'd say that any "development job" that is about software development is not trivial like you say.

I did say, "simplified too." Yes, there's other things you might have to learn, but being able to, "take data from some place, then stick it into a database"; and "take data from a database, and send it to some other place" is a fundamental skill set for a lot of dev jobs.

You might be working at a FAANG and get to do fancy cutting edge development that never touches a database. But a lot of us at banks, insurance companies, etc are piping data into/out of a databases or other endpoints all day long.

> An "endpoint-to-database" job doesn't exist

9 of the 10 dev jobs I've ever had amounted to this, including my current one. Half of my job is maintaining a Go-backend bolted to a Postgres DB, and the other half is piping data from various APIs into BigQuery or vice versa.

Very insightful and interesting comment. Thanks.

is it CS programs or is it the bootcamps?

I've seen the bootcamp crowd more often than not in these situations coming through, not many with actual 4 year CS degrees, though I've seen many of those too, but not nearly as much, by an order of magnitude.

EDIT: could be a difference in what part of the industry we work in too. I do more frontend / "design engineer" work.

Yep, I'm probably going to have to accept yet another paycut if I want to keep working. Peak of earnings for me was at about 13 yoe. Now it's downhill until I'm better off working retail.

Reply on news.ycombinator.com