[stareatgoats]

I think the answer to your woes is to accept that the computing domain (while labelled by a single word "computing"), in reality is so vast that no one can expect to be a master of it all. Most of us are content to carve out our own little niche; I for one have no idea what a video adapter card is, nor how Tex works, but I have good grasp of what a content editable element is, and so on.

The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.

[graycat]

My view is that the bottleneck is documentation or technical writing. As far as I can tell, so far nearly all of practical computing is conceptually easy. Digging into the work on the question of P versus NP does get tricky quickly, but so far that question is not very practical, e.g., with the question and the work so far, in practice can't do much with them.

For progress on documentation, as I hinted in my post, a first step is to define terms and acronyms. A second step for a term, concept, feature, etc. is some examples.

With reasonably good technical writing, I understand quickly.

E.g., for M.2, nothing I found from Google, Bing, Amazon, Western Digital, etc. made much sense. Then I downloaded from Asus a PDF of the basic technical information on a current, high end Asus motherboard and just looked at the board "layout" -- there it was easy to see what M.2 was all about, and the information was darned explicit, sockets on a motherboard, and highly credible, an actual Asus product.

To me, in short, for the computer industry and the rest of the economy depending on it, the issue is technical writing and, there, defining and explaining terms.

E.g., React. Okay, I gave the one line Google description. React has to do with writing JavaScript code. Okay. Even though I wrote the software for a Web site, I never wrote any JavaScript at all. Microsoft's ASP.NET wrote a little for me, but for how my site's Web pages work that JavaScript seems optional. So, first cut, for now, I can f'get about React and tools for working with JavaScript. In particular, if Lexical is mostly about working with JavaScript, then, again, first cut, for now I can f'get about Lexical -- but on this point I wanted to be sure, and so far I'm not.

[stareatgoats]

I'm sure good documentation, i.e. one that starts at a basic level assuming almost no prior knowledge and then gradually building on that, would lower the barrier of entry for many autodidacts. Maybe that will be the norm one day. But until then, we all find ourselves in the position where we need to quickly scan a text in order to assess if the level expertise required to understand it is within our potential grasp or not. Especially the texts that are posted here. Sometimes one might go down a rabbit-hole, google all the terms and see if it fits in with one's already acquired body of knowledge in an adjacent field, and sometimes one might find that one's knowledge actually has expanded.

Admittedly, that is the good feeling of having learnt something new. But sometimes it's just too many new terms and concepts to learn. I don't fret about it, one can't know everything. If one tries I suspect it would be a shallow understanding - except for the odd genius maybe. But I doubt it, even then.

That said, you can't go wrong with learning Javascript (Typescript) these days. It's really not hard once you've got a grasp of the basics and there is all kinds of documentation that guides even the complete novice. Writing a web-site without JavaScript at all is commendable (especially here on HN), but it doesn't hurt to know how it works.

[graycat]

Yup.