This may seem like splitting hairs, but both to you and to anyone in a similar situation, consider instead "skimming" the documentation rather than "reading" it. A lot of times the value of that first "reading" is just in getting a sense of what can be done and an idea about where it is documented. Certainly not memorizing how to do it on a simple read. There's a very popular unexamined idea that people retain things by reading them once and then will forever after retain it, but that idea is obviously stupid once I drag it out into the sunlight and point you at it. That's not the goal of a first read, and it's not what the vast majority of us get out of a first read. (Anyone who can operate that way is invited to make their own plans and let us normies discuss how to deal with our normal reading retention levels.)

I probably "skim" the bash man page once every couple of years and I still find new things that I blipped over every other time.

This is a great clarification. I actually do this a lot of the time (not always), but I do tend to skim the TOC and scan around before starting a new thing and it really is helpful.

As you said, it's a different than RTFM'ing, but it's an important clarification.

Thanks!

Same here. If I were to read docs cover to cover, not much would stick in my brain. I need top down research, start high level, and drill down where ever I touch base with practical applications. It's why I find interacting with LLMs so pleasant (ignoring their shortcomings), because I can learn exactly the way I want to and the way that works well for me.

The knowledge from reading all the docs won't be really "usable" but it gives you a vague, almost subconscious idea of all the things that exist and how they interact with eachother.

In general it is almost always better to learn using multiple styles instead of just one, if you prefer to do A then don't just do A but also try to do some B to improve your learning. Learning based on solving specific problems is good to get experience, but it is not good to get an overview of a field, you really want to get good at both the overview and the nitty gritty.

Also the purpose of reading a book isn't to become a master at implementing details, it is to get a good overview of the subject. You still have to practice implementations afterwards, but by having seen everything before your mind will now slot all problems much better and be more confident as you work through those implementations instead of looking up random advice on the internet.

I think of this as bottom-up vs top-down learning. I get frustrated working bottom-up one bite at a time; I need a map, I need to know the lay of the land and where I'm going. The older I get, the more I sense that bottom-up learners have an advantage, some sort of worse-is-better just-get-started kind of thing.

> I need a map, I need to know the lay of the land and where I'm going.

My visual image is a tree. I first need a rough shape of the trunk and branches, before I can start adding smaller branches and leaves.

Bottom-up then feels like having a bag of random leaves, instead of a tree.

This is what I mean when I talk about different kinds of brains.

Some of us need a certain amount of clarity and structure before we can feel good. This a great! Especially if we're aware of what we need and figure out how to get it.

Others of us have trouble building from the roots, and we're more effective probing around in dimly lit fog with occasional bits of moonlight illuminating leaves.

Eventually, we may both find ourselves in a well-lit forest, but we approach from different starting points.

The important thing (for me, at least), is to know which path I need at a given point in time and for a given context.