Programming

Depends on the docs but if they're written well you're best served by reading them in full. Rftm before looking at best practices and tips.

Problem is a lot of people don't understand how to read a doc. There's a terminology, phraseology, syntax. I have so many instances of people who say they didn't see the answer in the docs and then you look and it's right there. But the human mind tends to discard info it doesn't understand how to process.

If you think you know how the Internet works but haven't read the RFCs you might not know as much as you think you do. Read pretty much every one on ipv6 because the second hand resources are absolutely garbage.

I read the part I'm using. So if I'm configuring something I look through all the available options. But I wouldn't look through every functionality that's available.

Or if I'm working with a library I look at an overview of what classes are available and when I'm using a class I look at what that can do. But I won't look at every single part. That would overwhelm me.

If it's some new tool I want to learn I will read the docs.

If I have to implement/fix something I just search when necessary.

Depends. In the case of Angular the docs are very good so I read large sections of it. Doing the hero intro was really good at getting me up to speed.

For dotnet I don't like them. It's 50% reference manual and has few examples for the more niche things.

If it's readable and well organized, I read it. I did the vim tutorial because it was very easy to run through. Ditto for some of the Android lifecycle docs.

But there are a lot of bad docs out there.

Good question! When I’m learning a new tech usually try to search for best practices in configuration, then read the docs to see why the settings are being recommended.

Other than that I just try to remember where to find what I need

I love documentation if it's written well and if it's helpful.

I can't say I find vim's documentation meeting either of those criteria.

So I reach out to other sources who figured things out and regurgitate their experiences in ways that fit how my brain likes to consume them.

If it's something I will be using a lot and in depth (such as your editor case), it's worth RTFM. For other stuff just try to find the bit I need. It also depends to some degree how similar it is to other stuff I've used before. I may be able to grok a lot of stuff intuitively if it's similar to stuff I've done elsewhere. For instance jumping between versions of Unix was like this.

I read it. Saves a lot of time in the long run

I read, when you read you gain very deep insight if it’s written well

I tend to search.

If I know that’s a tool I will use a lot, I will try to read its documentation. I’ll just look up the basic info for basic tasks otherwise.

Reminds me how times ago I would install a new GUI application and then would just go through every menu, every setting, every dialog it had. This was much quicker than documentation and still gave me an outline of what’s possible.

Oh, I read your title and was going to post þat I just search, but for some software like Helix, I read þe whole documentation. I read tutorials, for Helix.

Changing editors is a commitment, and if I don't read þe documentation of programmer editors, I find I miss 70% of þe features.

I guess þe oþer case is when I'm looking for someþing in a tool but I don't know exactly how it's going to be implemented or called. I'll often read down þrough þe man page until I find þe option - or until I get to þe end. I've read þe whole ripgrep and fd man pages several times þis way. But zshall - it's huge. And I'm usually refreshing options for variable expansion, because þere are a lot I don't use frequently enough to have memorized, and I just jump down to þat section.