We're not talking about rote memorization here. We're talking about deeply studying something.
In the mid-90s I set up my then-employer's first WAN. Cisco 2501 with T1s for in-city links and frame relay for inter-city/international. As part of our Cisco contract, we got a full manual set, which was maybe 24" of shelf space. In my spare time over a couple of weeks, I sat down and read the whole thing. Then I went back and actually studied the parts that were relevant, mostly by reading and re-reading until it all made sense to me.
On top of that, I added a lot of practical experimentation with the gear. But foundational for me was really understanding the perspective of the people who made it.
Ah, that is different then yes. I think another comment alluded to it but much documentation these days is just simple reference material which without context is only so useful for deep understanding.
I fully agree with understanding the perspective of the people making the thing, knowing the what isn't always as useful as knowing the why. I speak a lot about being idiomatic, which is to say developing in a way that is sympathetic to the system and its existing approaches. That takes understanding the why more than the what.
I am reminded of the Honda motorcycle maintenance manuals. They are like being face to face with the engineers who designed the bike, reading that back to back would give you that deeper understanding of the system I think.
That's my pet peeve with auto-generated docs, they don't actually help much. I can see the function for myself, I don't need to be told it exists, I need to know why!
Aargh the thing that amazes me about people like you is the ability to push through when the docs don’t explain something before it’s referenced. How do you get past that point so quickly?
On the first pass? I usually just let it be. Maybe I'll mark it or make a note, but probably not. I've spent my whole life not understanding almost everything right away. If it's important, it'll come up again. It's sort of like starting a new job: you don't know who everybody is right away but you get it over time.
On later passes, I'm more inclined to jump around.
It is important to develop the confidence that you are not actually wasting time reading something which feels as if you understand almost none of it.
It is counter-intuitive because it tends to feel a little bit like a small child who has not yet learned to read, picking up a book and pretending to read by mimicking what the behavior looks and sounds like.
For what it's worth, I think this "deep study" mode of learning is perhaps less useful today in tech. We have a lot more things we need to work with with now, and a searchable internet means we can draft off other people's learning a lot more. Deep understanding is both less possible and less useful for the bulk of us, who are mainly integrating lots of libraries, services, tools, and frameworks.
But for every given topic, we still need deep experts, like Bruce Dawson was for this processor at Microsoft. So I think this mode is still very valuable, so I agree with Ciantic: this way of learning is something everybody should have at least some practice in.
What he is describing is just RTFM. It shouldn't be groundbreaking or really up for debate yet here we are. Manuals are written expressly for this purpose. A properly written manual has everything you need to know to get it working in a practical sense. Theory is a different matter altogether. But we are talking about engineering not science. Engineering is very much in realm of practical application.
If reading a manual front to back for a bit of tech doesn't tell you everything you need to know to use it properly then its not a good manual.
This applies well for some manuals and poorly for others. When technology changes fast you're likely to read a lot of deprecated stuff. It's an unfortunate state of affairs we find ourselves in.
I think it is my fault, I misunderstood that the GP meant RTFM where available essentially. Though I think it's still relevant, as what is clear to me now is that a lot of us are working with tech that has no true manual, just reference docs, which is a poor substitute for a real user manual.
My argument was essentially that you gain very little from memorizing reference docs. Reading a good manual is definitely invaluable on the other hand.
I am not sure why you were downvoted, this is a fairly common response to real world work. There is so much to know, and as systems get more abstracted working in the industry typically requires breadth not depth.
Is that good? Honestly I don't think so, it would be nice to be able to spend more time mastering a stack and using that, and I feel like the outcomes would be infinitely better than jumping ship every 12 months. But that is the reality of parts of the industry, it moves fast.
In the mid-90s I set up my then-employer's first WAN. Cisco 2501 with T1s for in-city links and frame relay for inter-city/international. As part of our Cisco contract, we got a full manual set, which was maybe 24" of shelf space. In my spare time over a couple of weeks, I sat down and read the whole thing. Then I went back and actually studied the parts that were relevant, mostly by reading and re-reading until it all made sense to me.
On top of that, I added a lot of practical experimentation with the gear. But foundational for me was really understanding the perspective of the people who made it.