Also, the documentation tells you what is intended to be public, stable API, vs. what's an implementation detail that may change with the next release.

Anyway, I used to work like this, but a couple years ago I just said "screw it" and started diving in and reading the source for libraries that I use. And that's been a very good decision so far. Using only libraries that are well-documented sets a ceiling on what you can accomplish, and hence makes your software less impressive and your potential rewards much lower. Everybody else can Google the web and read the docs; relatively few people are willing to dive into the source and understand how the library really works. The way to distinguish yourself from those people is to do what they're not willing to, and work on the hard stuff.

Some libraries are poorly documented because their authors are lazy, but many more are poorly documented because their authors are working on hard problems. If you leverage their work, even though it's not easy, you can work on hard problems too, and that's where most of the rewards are.