Indeed. In my day, a programming career started with
Karnaugh maps, and eventually progressed to assembler.
These days it's more likely to be Java. So many of the fundamentals, including system calls, are going to be a complete mystery.
Thus, your starting point may render the "fine manual" either inappropriate or indecipherable.
I dont think it's due to a missing link to the fundamentals, it's just: they don't do it (write manuals). And in the places where one would need the manuals, they say, read the source.
The fine thing about manuals is, they are complete and non-redundant. So, paging thru the manual you can be certain that you at least have noticed every option or feature the thing has. One will value that only later, when the problems arise:
ah, there was some feature, maybe I need exactly that now, lets check that.
As I occasionally mentioned, in the first decade I was in need of some frontend for a few tables I have in postgres. And, in an attitude of "rather overkill than limitations" I choose Ruby-on-Rails - mostly because OO is more fun in ruby than in perl. Then I had to learn a lot about Webservers, about HTML etc. - but it worked, the approach did what I needed (and more), and it was certainly a step in the right direction.
But - I didn't feel well with it. Because there was nothing that would deserve the name documentation, in the sense of a finite description of a component, it's purpose, and all it's options and features. So I could not really work with the tools, because I didn't know what they can do, how they would do it, and what would be the "best practice" for a given task.
Instead, the usual way of exchanging knowledge seemed to be to exchange "recipes" in blog entries on the web, about how a certain task might be achieved. This is good for directly reproducing the same task and quickly getting results (you don't need to know anything for that), but it is bad as soon as you need a variation that is not described in the recipe. Because you have no understanding of which are the "fishbones" - the parts that are really important and hold it all together (as opposed to those parts that are fancy and a rather matter of taste).
But this seems to have become the workstyle nowadays (I call it "demomaker" workstyle *eg*). One does no longer try and understand something down to it's roots, one just looks for a recipe to make it work. This is what that whole StackOverflow venture is about: exchanging recipes, with some selection of best practices. It is not about understanding what you're doing - probably that's not required nor intended. Consequentially, if something breaks, probably no one will know how to fix it.
