But in the end, your BS radar is your own.
It's generally better to read hard things. They're hard because they have a lot of information density or a lot of gaps. But that also makes people confuse poor readability for quality. Something that has no content tries to be hard to read by stuffing it full of gobbledygook. Whereas something that is trying to communicate an idea often goes through a few revisions trying to simplify the idea. If you have great ideas, you want the user to be expending their brainpower trying to comprehend the idea, not translating it into simple English. (exception is using jargon that's common to people at the right level)
Did you see this recent thread? It is a paper on how to read papers and it was very useful and insightful for me.
https://news.ycombinator.com/item?id=21979350
From the linked pdf:
"Researchers must read papers for several reasons: to review them for a conference or a class, to keep current in their field, or for a literature survey of a new field. A typical researcher will likely spend hundreds of hours every year reading papers.
Learning to efficiently read a paper is a critical but rarely taught skill. Beginning graduate students, therefore, must learn on their own using trial and error. Students waste much effort in the process and are frequently driven to frustration.
For many years I have used a simple ‘three-pass’ approach to prevent me from drowning in the details of a paper before getting a bird’s-eye-view. It allows me to estimate the amount of time required to review a set of papers. Moreover, I can adjust the depth of paper evaluation depending on my needs and how much time I have. This paper describes the approach and its use in doing a literature survey."
One of the major effects in software right now is that we pour such a staggering amount of effort into our current forms and patterns that it can create an overwhelming barrier to "better ideas", because there's just no way that even a much better idea can come out of the gate and compete against the behemoth of all the work done with the current paradigms. So we're stuck with patterns written into our systems from 40-50 years ago that can only very slowly change.
As a more concrete example, while my criticism of some things like "visual programming" as "the brand new paradigm that is going to revolutionize programming because nobody has thought of it before" has gotten down to the point I can virtually just copy & paste them to almost anyone who tries them (in the spirit of [1]), the flip side of my polished criticism is that comparing software platforms with literally billions of person-hours poured into them to some guy's hobby project, itself by necessity mostly built on the platform that embodies the wrong paradigm and tends to force itself on to the new project in various ways if it want to come out of the gate able to deal with real problems like "parsing XML" or whathaveyou, isn't necessarily a fair representation of what the project could be if it also had billions of hours poured into it. Unfortunately, as is the way of these things, if it's going to "revolutionize programming" it's got to actually be able to beat the current systems in some useful manner, fairly conclusively, right out of the gate.
As another example, no points for guessing that in a hundred years, computer CPUs aren't going to look much like a modern CPU. Perhaps there won't even be a "Central" processing unit anymore. But I promise you the current architecture will probably hang on longer than you'd guess (I wanted to say "50 years" and honestly got a bit gunshy about that... for all their orders of magnitude more transistors modern CPUs are clearly related to what we had 50 years ago today!). It's going to be hard for that new paradigm to compete with something with so much effort poured into it.
[1]: https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...