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?
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.I read it. Saves a lot of time in the long run
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
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
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.
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.
