I am talking about actual concrete solutions. “Do this code change and the bottleneck will go away”.

This person offered ACTUAL CONCRETE SOLUTIONS to performance issues. He literally opened bug-tickets and discussed with the team, and provided proof-of-concepts, but a FAANG manager attempted to shut him down.

This is not some snake oil salesman offering magic performance beans, this is someone who actually knew what they were talking about, and was able to diagnose performance problems in the operating system and solve it, for free. This isn’t some hypothetical, he REALLY did fix it despite being told it was impossible.

EDIT: Like the sibling poster said, the systemic solution is to "git gut". Which is clearly impossible as long as developers and managers foster a culture of dismissing performance, or in some cases inventing excuses not to work on it, as was seen in the Casey/Microsoft debacle.

The solution is to git gud.

There certainly was actionable advice in the couple of his videos I've seen (I haven't watched many, he's a wandering talker). But the underlying theme is about development process and frame of mind. Just adopting a list of techniques would miss the "greater than the sum of it's parts" value.

someone unironically espousing this as a "solution" to a struggling creator will never understand why other frameworks become popular when they cater to helping them out instead of throwing a book at them. That's why Unity is more popular among small creators. They don't necessarily want to be an engineer, they want to create art.

This mentality spreads outside of programming to other software as well. Gimp, Blender (which is fortunately making changes towards accessibility), etc.

You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not seeing that.

Like anything in software projects, the path of least resistance will get you to the quality floor. Trivially actionable advice doesn't exist because it will become part of the quality floor. That's just the evolution of software.

That doesn't mean there isn't actionable advice that's low on the learning curve. But like others skill, there is an unavoidable learning curve, it also takes time to apply the skill, and choosing when to apply it is a skill in and of itself. That's just life in development.

I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done. And the state of affairs is that performance is very frequently sacrificed, leading to a pretty damn sorry looking status quo.

Poe's law is in effect. I've seen that sentiment elsewhere and even in this post espoused unironically. It happens quite often in these circles unfortunately.

>I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done.

there isn't, but there is something wrong when you question the quality of a developer over it, while not understanding their constraints on knowledge, time, scope, and overall goals. It's just very presumptuous and I've never seen a justified case to shame someone as such.

Promote good practices, educate on bad ones. You can do this without such attitude as "git gud" which targets devs directly (which may not be something you said, but it is said often enough that I feel a need to address it).

Nobody is, though, and if you see other replies with the “git gud” text you’ll see this is used as a way to attack anyone who cares about performance.