Look, whether you’re a Linux user, a hardcore webdev, or even an IT technician, docs are a part of all of tech, but few people actually understand ...
For further actions, you may consider blocking this person and/or reporting abuse
What about documentation that is focused on theory mostly or thigns that are hard to get your hands dirty with it kinda stuff.
In those cases sometimes summarizing or dividing the text doesnt works.
For example, complex architecture design patterns or architecture and tools around it,
distributed systems , performance related stuff etc.
How do you guys learn these??it often requires a lots of concepts and codes that are hard to understand what it does..
Even then, you can still break it down and try to understand it.
Take the BitTorrent Protocol for example:
That being said, I totally get it. This doesn't work perfectly for every single thing.
Great as always. - And there’s no way you got a sponsor like brilliant.
I was also very surprised! Grateful nevertheless, but still.
tl;dr.
Actually had to make an account after years of lurking on dev.to, but I just couldn't resist... 🤣
But, having worked with Linux from before package managers really became mainstream, I've read my fair share of documentation (and I've received my fair share of, "rtfm"-responses on forums, often even if the info I sought wasn't in the documentation).
Documentation certainly is important, though, this way you lay it out is not my method.
Firstly, generally I prefer reference documentation vs user documentation. And I also don't retain much info just from reading documentation if it's not applicable to what I'm doing at that moment. In my mind it feels like trying to scoop water into a bucket using a colander.
If however I want or need something, I am really good at finding the info required. Years ago I needed to write something in postscript, and the blue book (and its green predecessor) was exceptionally useful, though I didn't read it. I just used what I needed.
We all tick in a different way. For me, I start work with a reference manual on a second monitor. Can't remember ever reading significant documentation before starting.
Counter point: write documentation that doesn't suck.
Most documentation for software is an active non-example for how to write documentation. At best it sort of makes sense if you already understand the software. Most documentation is full of circular references and completely undefined terms.
I really like this! Great read!
I don't always read the docs before starting on something if I already have a lot of knowledge of the language it's written in or thing similar to it. If I run into issues, I go looking for docs! Sometimes I also see if AI can solve it (but AI often does things in a way that works but not optimally).
Yeah, that's also what I do sometimes! It just depends on what I'm learning/using.
Interesting. Thanks for sharing!
Such a relatable breakdown...
Can't agree more on this. I don't get it why people don't read docs as much. You can literally get the whole idea of the project once you read it thoroughly
How I learn is to just wing it after reading the docs for something I need. I like discovering things I didn't know only after I've tried my own solutions for a bit, it's the only way I retain info
The smallest details in these post make the one who created the documentation learn about it again ..
Well organized and written .. Thank you for this
My favorite is how after the first paragraph, an article about "read the fucking manual" is offered as a video. 🙃
Is it a bad practice to first run through a tutorial video first to get a hands on, then dive into the documentation for better understanding afterwards? I find it a bit interactive if we build something through hands on, even though we might not understand the concept at first, but then we'll get better at it when we review our work to know why we do what we do.
I don't see why not. If it works for you and helps you absorb the information faster or better, go for it!
I think it's important to skim, preferably just reading function calls, as reading pages takes time. I learned the parsing library lark, with a background in parsing, through skimming plus letting gpt generate test programs for the feature I was interested in. Testing by book just requires more more iterations and page flipping.
Read the documentation before asking any questions, obviously.
I can relate to youtube tutorial hell when I was very new and didn't trust written tutorials due to versioning or if there were some implicit steps anywhere. Years later I was once asked to make a video also by someone with a gaming background, who did not appear to trust written documentation.
Whereas I will avoid video tutorials at all costs, even abandoning one resource and seeking out another, if the only option available that covers a particular topic is a video.
But then, I'd already begun to realize our approaches are polar opposites the moment you mentioned ChatWTF.
I think that if more people learnt speed reading the documentations would make more sense. Reading them slow can result in distractions and boredom, but the focus needed to speed read helps with the absorption