> Need to use a library? Then first read the documentation, then read the source code, so you actually understand what it can do, how it does it, that it's not magic, what its limitations are, how to use it, and if you actually need it.

That's the opposite of thread OP's advice. If you need to use a library and you're impatient, find the closest example to what you want to do and then hack away at it until it does what you want.

It's an elaboration of his advice, not the opposite. Please be patient enough to read all of the OP's advice:

>But read articles every once in a while on best practices so you aren't learning the "wrong" way to do things.

>The big drawback is that there are a lot of Google results that are outdated, novice, or flat-out wrong.

>My general advice: consult official docs whenever possible

After you read the official docs, and decide you actually want to use a library for something that's not trivial, one-off, or throw-away, it will benefit you to actually read the source code itself, which is by definition not out-of-date and incomplete, like so many of the articles about the library you can find by googling and reading stack overflow.

In my book, hacking away at using a library until it does what you want involves reading the source code in the developer tools by setting breakpoints and browsing the call stack, function definitions, local variables, and data structures, while the code is alive and running.

Once you've done that, it's a lot more interesting and easier to then read the entire source code on github front to back, to learn the library well, because you will have a lot more context about how it's actually used and fits together, its dynamic runtime behavior, and the shape and texture of its objects and data structures.