If documentation is written in a readable and confluent way, RTFM isn’t such a big deal. The issue comes with overly draconian and non-confluent documentation.

What the … LOL

Depends on what I am doing. Walky Talky? Toaster? Dish washer? … Who needs a manual for that?

FID detector? I need to know several things before turning it on. New Mainboard? Why is the WoL setting behind wake on PCIe?

I mostly try to read the docs, but sadly good documentation is pretty rare.

well I'd read the documentation if websearch wasn't so shoddy that I could find it in the first place /s

i stopped reading most docs after like 95 unless they are rfc or reference and i had a memory that was stellar

now, i read all of them over and over and over because i got a tbi from electroshock “therapy” and i am working with shitty autobiographical memories and cant get to the details. so i read, keep reading, and make sure all the mans are at hand along with my references. now i get frustrated and wanna die but i still get it done but im always like yeah uh no

I prefer to raw dog it first, break it, then tuck me dick and read the paper like the real alpha male

It’s weird that Linux certification requires rote-memorization of commands. The only people who make any effort to memorize commands are newbies and people studding for exams. You will always have access to bash history, man, and --help, even from an offline machine.

Every command I’ve memorized is simply the natural process of repetition. Is that your experience?

ln -s $NAME $TARGET

Man pages tend to assume a lot and overload the user with information.

Forums are full of “duh, haven’t you read the man pages, idiot?” kinds of people.

Web searches are full of AI/garbage (same thing) articles that focus on distros/programs that are either horrendously inaccurate, out of date, or simply don’t exist anymore.

Therefore, I utilize the tldr man pages, and use extremely specific terms for web searches.

"F* you, I won’t read what you tell me!"

• Rage Against The Manual

I find that the docs usually consist of a quick start guide covering some ultra tight scenario that doesn’t apply to most people, and reference material that’s just some total brain dump of every possible command without any kind of context.

Oh it happens to the best of us. I was working on a simple cron the other day with the cron string that would insert the cron into my cron config something like ‘echo’ and the normal string you’d recognize, and ended with a ‘-’. I wasn’t paying attention and issued the command which did insert itself into the cron config, but in a manner in which I didn’t want. It replaced the whole cron file with that one string. #$@^$$ Luckily I have a cron to back up the crontabs.

I also don’t RTFM

I have found the docs the best place to start with anything, but have found that some don’t know how to write good documentation.

Also man pages and the tools own help -? Or -h

If you run something that has pants docs, you could always see if there is a way to help update it

I volunteer as developer for a decade old open source project. A sizable amount of my contribution is just cooking up decent documentation or re-writting old doc from the original module authors written close to a decade ago because it failed me information wise when I needed it. Programmers as it turns out are very ‘eh, the code should explain itself to anyone with enough brains to look at it’ type of people so lost in the sauce of being hyperfluent tech nerds instantly understanding all variables, functions, parameters, and syntax at very first glance at source code, that they forgot the need for re-translation into regular human speak for people of varying intelligence/skill levels who can barely navigate the command line.

I worked next to a technical writer for Unix; the Unix. One of the things we were known for, actually, was the amazing documentation. This guy and both teams of writers (that many) maintained the doc as their entire job. It was written well, it was spell-checked, it was accurate, it was accessible. If you installed the machine, it was on localhost/doc or so.

Almost all tech writers were turfed after Y2K. They cost money and didn’t earn directly.

If you notice a lack of good docco like you notice a lack of mentoring in code dev (I see you, Systemd), then we know how we got to this stage.

If you become CEO, just keep that in mind.

While investing money to create good documentation is the preferred way, I cannot trust it to be accurate in this day and age of cutting corners. It takes a bit longer but I’ll always look at the code itself to get me closest to the truth of what is going on under the hood.

Lol reading the source has trained me to try reading the documentation.

If it’s good, it’ll save hours or crawling through code.

Nothing teaches you what the documentation says like plowing ahead without reading it, fucking something up badly, having to crawl back to the documentation hat in hand and actually read it.

RTFM. …
… The last thing you try.

I do read the docs. Even before trying software, to judge if ot will fulfill my requirements… Rocky Linux is one such example. Great docs, I’d love to try their distro one day :)

I had a boring manufacturing job with long gaps between batches of work, so I read every help file in Windows NT4.1. While reading it, I found a way around our IT limitations on which apps we could run, and learned how to write scripts. So I wrote a password protected launcher tool using a macro feature in a terminal emulator I had access to on my workstation, and then started reading the man pages in Unix sys-V.