The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.

But this isn't their job. Their job is to hire someone who passes the hiring bar. If they can do that without ever looking at a random resume everyone at the company is happy.

An unstated thesis of the article is that several years from now people who want to accomplish that job just won't look at resumes submitted online - whatever anyone's feelings about it.

> Engineers in particular have expressed their desire to focus their time on engineering, without being hampered by slow process flows

I'm guessing ASML had a lot of regrettable attrition and heard this in the exit interviews.

Stepping back - my experience is that points are solving a problem good organizations don't have.

The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.

I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.

Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.

Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.

If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.

I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.

I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

Aside from AWS, who's famously bad at this, my experience is that this is usually because people want a faster career push.

Imagine Jim, 8 years into his career. Jim is pretty good and his work takes him 30-40 hours a week. If he worked another 5 years in the same role it'd probably drop to 20 and be chill.

Jim wants to get promoted. If he waited the 5 years he could do it working 40 hours a week. But he wants it now, and since he's not as good as he will be he needs to work 60. What does Jim do? He works the 60.

There's nothing wrong with this choice, I made it, I'm happy with my choice. I might make it again in the future, or not.

I may be reading too much into your post but I'll say that this sentiment is a common pattern I see in many competent senior folks who think they deserve promotions into roles above senior. Getting along with leadership is a huge asset for for this type of leadership role. It means that you stay aligned and push in the same direction together.

If you're not going to get along well with your leadership you need to be much much better than everyone around you - which is a significantly higher bar to clear. And getting along well is a skill. It's usually not the skill people want to learn but it's hugely valuable to be able to be chummy with a difficult exec.

It's a good deal if you deserve the promo. Giving someone the opportunity to take on projects at the next level and having them not deliver can be enormously expensive. The higher the level, the more expensive it is.

The statement I like to use as an analogy to this one is:

"I don't need to know how to add or multiply numbers, calculators can do it"

This is true in a certain sense, but if you are numerate you know that speed with numbers allows you to do all kinds of quick checks that less numerate peers cannot. It's my experience that colleagues who don't get good at leetcode style problems don't actually understand the skills they've left on the table.

Odds are that until you can get past this mindset, you will hit a similar wall in every career, it will just be less obvious to you that you're hitting it.

Success at most careers means a lot of tedious grinding out basic skills. If you're lucky you like the grinding, but that's rare.

And here's the important part - getting better at this stuff makes the job more fun, humans really like the feeling of mastery. My first 4 years in SWE were miserable because I had no CS background. But I ground really hard on textbooks and leetcode, every minute of which was uncomfortable, and now my career is awesome!

Maybe SWE isn't for you, but whatever you do, commit to the work.

User education, for example, can be done in ways that don't even feel like gen AI in ways that can drastically improve activation e.g. recommendation to use feature X based on activity Y, tailored to their use case.

If you won't even lean into things like this you're just leaving yourself behind.

Everywhere is like this to some extent - no people can be an expert in all things.

Quite a few of AWS's more mature customers (including my company) were aware within 15 minutes of the incident that Dynamo was failing and hypothesized that it'd taken other services. Hopefully AWS engineers were at least fast.

75 minutes to make a decision about how to message that outage is not particularly slow though, and my guess is that this is where most of the latency actually came from.

The brass tacks are:

1. Estimates for the cost of obesity globally are somewhere around 2 trillion dollars.

2. Telling people to diet and exercise usually did not get them to lose weight

3. Giving people semaglutide does get them to lose weight

So many people in my life who were unhappy and struggling with their weight are now happy because semaglutide worked where advice about diet and exercise did not. I can't imagine most rare disease drugs will have that level of impact.

This seems to describe what good engineers above the senior level do. Certainly everyone with a PhD I work with who rose through the ranks said that being very senior was a lot like being a good researcher - albeit with much more pressure on execution.

The "stop spitting in your soup if you pay us extra" is really efficient market segmentation. If you don't do that you need to find actual value props that separate the market in just the right way to generate the financials that allow the product to keep going as is. 9 times out of 10 the result is that failing PMs totally fuck up the product and everyone loses.

It's the SSO kerfuffle in a different package - terrible, but the right choice surprisingly often.

1) I watch youtube more than any streaming service

2) I really really value not having ads in my life

So the price for ad-free youtube really seems phenomenal. None of the other features really matter to me - ad free dominates all value discussions.

1) You probably already have Redis running

2) Adding a "good enough" rate limiter is easy

3) Faster solutions are usually more work to maintain given modern skillsets

If you are a b2b SaaS company odds are your company will exceed 10 billion in market cap looong before Redis rate limiting is a meaningful bottleneck.