Exactly. Imagine the board meeting where somebody has to suggest “maybe we don’t want that many more users.” I was about to type “customers,” but realistically a significant portion of this new load is on free plans.

To be clear, that was during recovery, not a root cause.

The closest to that is this:

Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.

One could argue they still DDOSd themselves by promoting tools that produce commits at a much higher rate.

Only the time I took to play around with FOSS options, which is fine for a hobby. There are actually really good options out there, they just don’t match my needs.

In concept, absolutely, but I tried and didn’t like.

I’d say the desktop offering is the main thing, but moving further into the cloud could be an interesting move on the subscription journey. Not interesting for me, as a user, but as a concept and an investment for the company.

[raises hand] I’ve used MatLab instead of Photoshop, I guess.

Seriously though, as an amateur photographer, working on a new engine instead of just adding more gen AI features to every pixel sounds like a good move. I’ll be sticking with my buy-once option, either way.

As a developer I also found this interesting:

Can make steady progress even when a problem is ambiguous or not fully prioritized yet

That’s a super important skill a lot of people don’t even want to develop.

Ah, OK. What’s the expectation these days, if you don’t mind me asking?

Is that salary estimate also from 2011?

There’s a more robust methodology here, which is to look at commit history, but that will only tell you how many lines were pushed and merged. That will be a greater number, by the way: say the kernel is 100 lines, somebody may have written 50, but they may have all been replaced by future patches, so The number of lines written is greater than the number of existing lines.

Regardless, I’m sure you already know lines of code is a bad metric of output, let alone effort and work.

Lie-to-children. See also “perfect is the enemy of good.”

This was very hard for me to understand, particularly when the simple answer in school that was provided for the benefit of the rest of the class didn’t come with a deeper follow-up, but I now recognize the great value in meeting people where they are.

I’d say it’s a lot more convenient to write bad C than bad Rust. To put it another way, Rust shifts frustration left and can be disheartening for some people.

Yes, I agree completely, but we don’t have a bunch of Assembly diehards working on Linux, so the parallel - while accurate - feels out of scope.

Ultimately, it comes down to thoughtful transitions over a reasonable period of time.

I still understand the argument of the C greybeard to Rust knowledge gap though. Objectivity, it’s hard to argue for a spidey sense that took years or decades to develop vs a deterministic and strict compiler, but developer (and reviewer) experience often seems to be rooted in personal comfort* more than in language features.

That said, we all have to deal with transitions and learning consistently leads to better outcomes. The argument is sound, but the pragmatic dynamics may take some time.

*”personal comfort“ doesn’t mean the language or tools are somehow objectively comfortable, but that people feel good, confident, productive, and happy working with them. Just yesterday I was thinking that I like the Gir “is hard” - it stimulates my brain on a daily basis. Different people get that in different ways.