Screaming into the void of the blogosphere is catharsis for getting my SO question closed.
And because I know you're all nosy, the SO question is here: https://stackoverflow.com/questions/79605462/high-cpu-usage-... . Please feel free to point out more ways in which I screwed up asking my SO question.
1) clearly technical
2) reproducible
3) has a clear failure condition
Not be a suitable candidate for S/O?
Did we step into a dimension where only "How do I print('hello world')?" is a valid question while I wasn't watching, because it has a trivial one-line answer?
Hard questions doesn't mean they're bad, it just means many people aren't competent answer them. The same goes for obscure questions; there might just not be many people who care, but the question itself is entirely valid.
Does that mean they're not suitable for S/O?
I... can't believe anyone seriously believes that hard niche problems are too obscure or too hard for S/O to be bothered to grace themselves with.
It's absurd.
It just baffles me that a question that might take some effort to figure an answer out to might 'not be suitable' to S/O.
The problem is complexity and scope.
We don't debug code for others. We expect them to find the specific part of the code that is causing a problem and showcase a minimal reproducible example. For performance issues, we expect them to profile code and isolate bottlenecks - and then they can ask a hard, obscure question about the bottleneck. Or a very easy one, as long as it's something that could make sense to ask after putting in the effort.
In short: we're looking for a question, not a problem. Stack Overflow "can't be bothered to grace itself with" hard niche problems, or with easy common problems. But it is about answering the question that results from an analysis of a problem. Whether that's understanding the exact semantics of argument passing, or just wanting to know how to concatenate lists.
And we're looking for one question at a time. If there are multiple issues in a piece of code, they need to be isolated and asked about separately. If the task clearly breaks down into a series of steps in one obvious way, then you need to figure out which of those steps is actually causing a problem first, and ask about whichever steps separately. (Or better yet, find the existing Q&A.)
(Questions seeking to figure out an algorithm are usually okay, but usually better asked on e.g. cs.stackexchange.com. And usually, an algorithm worth asking about isn't just "do X, then do Y, then do Z".)
Stack Overflow is full of highly competent people who are yearning for questions that demand their specific expertise - recently, not just in the 2010s.
Most questions I've asked since 2020 were deliberate hooks to deal with common beginner-level issues or close FAQs that didn't already have a clear duplicate target. (I've stopped contributing new Q&A, but still occasionally help out with curation tasks like editing.) But I asked https://stackoverflow.com/questions/75677825 because I actually wanted an answer, and it's an instructive example here.
Answering it required detailed expert-level knowledge of modern CPU architectures and reverse engineering of the Python implementation. Asking it required noticing a performance issue, then putting extensive effort into simplifying the examples as much as possible and diagnosing the exact qualities of the input that degrade performance - as well as ruling out other simple explanations and citing the existing Q&A about those.
But demonstrating it requires nothing more than a few invocations of the `timeit` standard library module.