Magmalgebra

The title only so matters to the extent the company is a known entity.

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.

> get a lot of junk applications, but frankly, it is your job to sort through them.

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.

I think the press release is actually clear that they felt this was necessary to retain talent:

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

By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.

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.

> The process is quite easy to implement

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.

> is in points not days

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.

> But in my experience, your manager is expecting you to do all of your assigned role (e.g. write code), but then also do a bunch of stuff on top -- e.g. leading and taking ownership of new initiatives that is extra work.

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.

> that got along well with leadership in a fast growing company

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.

> This has always struck me as a pretty juicy deal going for the corporation.

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.

> You run into other tools you have to cobble together as part of actual work, but you never have to memorize those particular tools

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.

> I hate leetcode and that keeps me away from most of the job opportunities

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.

Yeah. For all the excesses of the current AI craze there's a lot of real meat to it that will obviously survive the hype cycle.

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.

Standards come from a mixture of culture and attention. The reason SF pizza is so much worse than NY pizza is that SF does not have culture of high quality pizza (I say this as an SF native). Conversely we have higher standards for Sourdough. Seoul has higher standards for Kimchi, you get the idea.

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

Depends on what you're measuring.

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.

Most of your complaints are about things that are not React. Those are optional. I can still standup a vanilla React stack in an afternoon just as easily as I did 5 years ago and immediately start writing the exact same code and have it "just work".