For that reason, I would say that the amount of time I spend reading documentation is significantly less than then amount of time I spend reading the code.
For documentation authors, I'd recommend focusing on giving the reader the high-level context necessary to understand the code. It can be hard to dive into that. But things like "an error will be returned if these 86 conditions are true" probably should be a reference to the code, because you know there are going to be 87 conditions tomorrow and you'll forget to update the documentation.
As for your actual question, it can be hit and miss as to whether or not you can go into depth in something by merely reading. I have not found a book about modern Javascript ("use the axios library to make HTTP requests from your code") and just have to cobble things together from existing code, googling for the current problem I'm having, etc. I imagine that sucks for people new to the field, but I suppose is why you get paid for having experience. For things like SQL, you can definitely find a book about it, as it's been essentially the same for my entire life, and what really matter are the fundamentals of relational databases... the Postgres-specific things you will probably discover while doing some work.
So I guess what I'm saying is... focus on getting experience. If you tell yourself, "I want to write 'foo' in Javascript" you will learn Javascript somehow. It's not as easy as just reading something, but it will stick with you forever. And when you run into the inevitable obscure error message, realize that you can just read the code to figure out what's actually happening. You need not be dependent on a secondary source when reading the primary source works. Because someday, you will be paid to work on code without documentation, and you will need that skill.