> There's nothing wrong with this choice [to work extra hours to get promoted].

But if there are limited slots for promotion, and that's generally always the case, the resulting competition among deserving engineers makes the extra hours more or less mandatory. Say that Amy is a better engineer than Jim and gets a third more done per hour. If Jim puts in 60 hours instead of the expected 40, then Amy isn't going to beat him for a slot unless she also starts working extra hours.

In the end, promotion becomes more about grinding than being effective. That's not great for company culture or retention of top talent.

That doesn't make the promotion more about grinding because the company doesn't care about how much work you get done in a set unit of time compared to other employees in the same set unit of time. The company cares about how much you get done, period.

If the only differentiating factor between Amy and Jim is quantity of work done (this is never the case in real life), most companies will prefer a Jim that works 60 hours to an Amy that works 40 if Jim is producing 5% more.

> most companies will prefer a Jim that works 60 hours to an Amy that works 40 if Jim is producing 5% more.

What happens in reality is that Amy produces 10% more in 40 hours than Jim in 60 hours, but she's not a team player because she leaves at 5.

In software development, sure (maybe). Most jobs aren't software development.

The vast majority of jobs your production slows as hours increase but there isn't a tipping point where you're less productive, even after accounting for errors or rework. There's a reason CPAs don't clock out at 37.5 hours during tax season, or warehouses or service desks or any number of things other than the specific thing most of us do often work more than 40 hours a week, especially when actively working to get a promotion.

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

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

Maybe I’m not good at the basics, but as an ostensibly quite successful engineer, I have rarely had to do “the basics” at work, and I don’t see how leetcoding would improve my actual performance.

Leetcoding is basically testing how well you can cobble together solutions out of a decently large bag of tools. You run into other tools you have to cobble together as part of actual work, but you never have to memorize those particular tools.

So leetcoding becomes memorizing an arbitrary feeling set of tools that you never actually have to use in practice just in order to prove that you can cobble together solutions on the fly using the tools.

Certain personality types bristle at being told to memorize a large set of things for no practical reason. It feels subservient to do so.

Now if what you are really saying is that forcing yourself to feel subservient is required in a lot of careers in order to succeed, then yes totally :)

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

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.

>here's a lot of real meat to it that will obviously survive the hype cycle.

Okay. When the hype cycle dies we can re-evaluate. Stances aren't set in stone.

>If you won't even lean into things like this

I'm sure Andy knows what kind of business was in his clients and used that to inform his acceptance/rejection of projects. It mentions web marketing so it doesn't seem like much edutech crossed ways here.

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

I’d argue it’s easier than ever today, thanks to Vite

While I get what you're saying I don't think this is what most people think of as "solved".

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.

The advice about diet and exercise did not fail to work. What failed was listening to that advice. It works for people who listen.

And what is more you will not be healthy at 80 years old living otherwise sedentary life with ozempic keeping the weight you should be carrying off. You will have no muscle mass. You will be frail and in poor health compared to your peers who cultivated and maintained muscle mass through their life. You will not only have a weak body but your organ health will be in decline. You will have weak lungs and heart. This is going to make medical intervention at the end of your life all the more complicated. Make it difficult for you to survive from things.

Now imagine how much of the world might change if we solved the issue of "uninformed people failing to listen to expert advice." I imagine we'd meet all our climate goals and pollution goals in a generation if not less.

> Most standard software engineering jobs don’t require that kind of research activity (although it does require some; product development is a creative process)

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.

I think it totally depends on the job. It's like a process running on a CPU. I've seen software development roles that are "batch processes," where the developer goes into a cave to crank through his tasks uninterrupted, and then emerges in a week to deliver the results. And others that are "interactive, event-driven processes," where there is a lot of back and forth between product owners, UX, and other stakeholders, and lots of iteration and refinement. And then there is a whole spectrum in between! One size doesn't necessarily fit all development styles.