Any time I run into one of these, I'll post a reference to the actual docs as a comment in the top/accepted answer.
Well yeah, what's wrong with that. Eg I work in construction I build concrete. I don't know about the various strengths and mixes of concrete. I just know my little field. Me trying to get the perfect concrete mix or designing the rebar would be bad because I don't understand engineering.
It's neither efficient nor productive for everyone to be an expert on every aspect of the tech they are using.
If I have a problem with one tiny aspect of a computer program I shouldn't have to gain an understanding of the underlying framework. I just need the specific task to solve my particular problem.
I want to use flutter to build an app not to understand the details of how these iOS and Android platforms and underlying tech work.
But by asking the question on SE, they can get someone else to go to the trouble of doing a keyword search on the table of contents to find the relevant chapter, then paste in the first paragraph of that chapter.
It's laziness, pure and simple.
If you don't know an answer offhand and haven't worked with the specific part of the program the question is about then there might be an issue with implementing the docs you are unaware of.
Assuming the asker is lazy, didn't read the docs and just linking the docs isn't actually helpful behavior. Please do not do this.
There is such a thing as overloaded and non-user-centric documentation that is rich in details (if you already knew a few Emacs-type keywords)
While it is detailed, it can hardly be called overloaded. The real reference material is in a completely different book, the Emacs Lisp Reference Manual. There is also a FAQ, and if you’ve never programmed in Lisp before then there is the Emacs Lisp Intro. Then there are something like 60 other manuals for various packages that come with Emacs, like Org Mode or the calculator. These all serve to keep the core manual from becoming overloaded with details.
You can read them all online at <https://www.gnu.org/software/emacs/manual/>, should you care to try to prove me wrong.
I estimate that about 30% of questions on the Emacs StackExchange can be answered by quoting from that core manual, another 20% by the FAQ, 20% by the Elisp Intro, the Reference, or the docstrings of individual commands, and another 10% by the manual for Org Mode. The calculator comes up occasionally too. Perhaps 10–20% of the questions on the site are actually interesting questions that require real thought or a look at the source code.
From what I’ve seen, it is also something that comes with a mature team, as some stability is needed before a team starts to talk about documentation and standards. The constant churn of teams hurts documentation and error messages a lot. Why bother documenting or writing good errors if you won’t be around in 2 years to deal with it? More people need to stick around long enough to feel the pain of their bad decisions and laziness.
I'd just like to add -- shipping fast and constantly adding new features has pushed _almost everything else_ -- including design, and product quality -- to the backseat. Design documents are a rarity these days, forget about well-written and well thought-through design documents.
Documentation for pros by pros, often even with topic specific language. Thus useless for beginners.
Stackoverflow is concept error filter feeding.
Search -> Do you actually mean -> better Wikipedia -> duplicate of actual answer using specialist prose.
Baseline code also seems to be well documented as a rule. However modules in a lot of languages, even important widely used modules are too often very poorly documented.
