I’ve been switching from Vim to Helix recently. I did the built-in tutor, and whenever I need to configure something, I look it up in the docs. The problem is, I only find what I already know to look for. Without reading the documentation more broadly, I don’t really know what I can configure in the first place.
So I’m curious, do you sit down and read documentation to understand a tool, or do you just search it when you hit a specific problem?
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.
Problem is a lot of people don’t understand how to read a doc. There’s a terminology, phraseology, syntax.
This reminds me of the ExifTool documentation… It feels like a well written documentation (and probably is) but the lack of context as a non programer can be overwhelming ://.
Thankfully, the forum was of great help and the maintainer is still active after all these years… Incredible tool by the way !!!
I see the value in reading documentation front-to-back for picking up all the little tidbits of information (or at least knowing where they’re documented), but yeah, ultimately I need to be building something to really process the information.
Kind of my sweetspot is documentation that makes you build along, but doesn’t overstay its welcome. As in, don’t cram all the details along the way, but rather just dish out important information on rapidfire.
I will run off building my own thing in the middle of the tutorial, if that isn’t the case, whether I want to or not. As soon as it’s quicker to learn by dicking around with the code, I will do that and then I’ve spoiled future chapters, so likely won’t return.As a great example of the last point I LOVE this thing. https://doc.rust-lang.org/stable/rust-by-example/
Rust has an official book but it also has this list of runnable programs going over the features and usage.
So when I want to quickly see/remember a topic I can just look at it but if I want to learn inner workings in more detail to mess around with I can search it in the other documentation.
Damn, even when I don’t mention it, it’s apparently obvious that I’m gushing about Rust. 😅
I had the Rust CLI Book in mind: https://rust-cli.github.io/book/index.html
Especially, if you have experience in another language already, the first chapter shows you how to develop and ship a useful Rust application in a short amount of time. And then the second chapter contains all the detail information, which you might need, after you’ve run off and started building your own thing.But yes, Rust By Example is also really great. It happens a lot that you search “xyz in Rust” and it’s one of the first results, and always worth clicking on.
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.
I read it. Saves a lot of time in the long run
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.
I read, when you read you gain very deep insight if it’s written well
I tend to search.
These days I prefer reading manuals and documentation to get the most basic version of anything running and then build up on it. If anything goes wrong, I go to stackoverflow
Usually, I use the documentation when I need to look something up, but I’ll generally read around the specific information that I’m looking for.
