More seriously, I think that we have been trained to rely on just in time searches (or ChatGPT sessions) when we encounter the next thing we need to learn. RTFM is just so time consuming and I personally don't recall everything I have read, leading me to rely on search/AI to re-learn the next thing just in time anyways.
In some ways this is a vast improvement, which is why it's the default behavior now. Why cream your brain with information you might never use?
But it DEFINITELY has a weakness in that you don't know what you don't know. I never knew about this 'trap' trick, for example... and I didn't know I didn't know it, despite it being something I see as quite useful.
Side note: I think RTFM has historically meant "try to find the answer first before asking for it", leading to me designating LMGTFY (Let Me Google That For You) as the modern equivalent in this just in time searches reality we live in. I wonder how long it will be before we start saying LMAAIFY (Let Me Ask AI For You)...
You can spend twice as much time over twice as many years reading random blog posts and googling, and you'll have no cohesive, comprehensive picture of the full tool and all its features. In this case, if you look at `man bash` and find the trap builtin function you'll learn about the DEBUG and ERR traps, for example, which I didn't see mentioned in the discussion here. These things might be useful to just file away; in case you ever need it someday, then you'll know it's there and exactly where to find it, not some half-remembered blog post you can't find again.
Over ten or twenty years, the difference between these two habits is night and day. The people who read the documentation first, and only then ask for help, and the people who ask for help first and get it and so never read the docs, end up in a totally different place with respect to overall confidence and comfort with the tools. Reading the man page means you don't get your answer right away, it's slower, less enjoyable, and less fun than googling. It's competing with content that was literally filtered by an engagement selection process. Of course it's less immediate gratification. The only reason people will do it is if they internalize the habit long enough to appreciate the benefits.
"RTFM" was a bit of social shaming, to tell people "don't be lazy, the answer you seek is literally in the documentation, please just read it". Shaming strangers on the internet turns out to not work well at scale, so generally we don't do this now, and the message just doesn't get passed on at all.
I've been shocked at the attitude even in some companies that reading docs is some kind of unnecessary or obsolete practice. As you say, it's become the default option to seek answers online. A culture of reading documentation still exists, but now it has to be maintained inside organizations that care about it, because it's no longer understood as the basic professional attitude.
There's incomplete documentation. There's API documentation without examples (ie specification but no example/tutorial). There's outdated documentation!
I can also say that I started studying SQL by reading the docs for mysql, and after an hour I was still stuck inside INSERT or SELECT. Reading about all use cases in detail was not useful to learn a first approach to the queries!
So I'd say that this "truism" isn't always true. Sometimes the docs suck or don't provide the info you need at that time.
> Over ten or twenty years, the difference between these two habits is night and day. The people who read the documentation first, and only then ask for help, and the people who ask for help first and get it and so never read the docs, end up in a totally different place with respect to overall confidence and comfort with the tools.
Ooof! This one's hit home.
I think this might be a bit easier to appreciate if you've ever worked at a young company and made choices because you have to (oh, we'll use MySQL, that sounds better than Postgres) and then give yourself an extra three months work in two years when you finally come up against a shortcoming in the tech. We have to make an awful lot of decisions and generally don't have the budget in time or money to fully grok the options we're deciding between.
Easy! It is a reference manual. It documents every feature, even those that you should not use, does not discuss pitfalls, and does not discuss the best practice. Even worse, there is sometimes a disagreement whether using a particular feature is a good practice. Often there is a factor of adjusting your code style to something that is not too advanced for other people to review.
There seems to be a common sentiment that cargo culting random opinions from the internet is a "best practice" and that no code reviewer should ever have to learn anything new during the process. Both of these opinions are in my experience a fast track to a culture of mediocrity.
Besides, it is slightly ignorant, and if I may say so, it can be a bit neurodivergent.
You see, manual pages are more often than not the wrong type of document to point people to.
`man` pages are information-oriented. You can (or should, if they are well written, which is not always the case, but that's another matter) find all the information about a piece of software there - they are references. As you say, it's something that needs to be digested before you can use it.
There's a certain kind of person, very commonly seen around computers, which can't help but digest a manual before they use a tool. Often they enjoy doing that. And that's fine. But that is not how everyone else does things.
People often have a particular problem they want to solve. They want to know how to zip a whole folder, or generate a ssh key with a particular algorithm. Whatever. Something concrete. They want to solve that, they don't want to "digest a document in order to solve that". That is not something those people enjoy, or are good at.
What those people need is a goal-oriented doc. Something that has a list of possible problems, and then gives solutions. Something that they can search for "whole directory" and find what they are looking for quickly. Something like a FAQ. This does not exist for all command lines (although the `tldr` app fits that well often enough for me).
Blogposts are often (yet another) type of documentation, they are learning-oriented. Like a tutorial.
The thing about blogposts is that they are indexed by Google, Bing and others. So in effect the combination of Google+Blogposts works like a big FAQ document.
Please understand that I am not trying to be offensive here.
You don't have to be born loving knowing how things work. But if you want to be a programmer (and most people don't) you should accept that the people who understand how things work are eventually going to run rings about people who don't. So you can either cultivate curiosity in how things work, or you can cultivate the habits and fake it till you make it. You put in the work if you want to develop a skill. There's no magic in it.
If you're not interested in being a programmer, then you don't need to waste your time reading man pages, obviously.
Programming is a vast ocean and very few people are going to know every single detail of ever single nook and cranny. If your day to day involves bash scripts, sure, learn and digest all of them. If you are a python programmer and you just want to compress a file you don't need to know all the flags that `tar` supports.
Not that I regularly read them all myself, but it's nice to be rewarded with a new dark art (like alias-based ~metaprogramming) every once in a while.