Hi
To be honest this kind of mindset is what makes developers keep back from helping beginners in public forums. It also leads to the wrong conclusion that it's not worth the effort to invest time as *those people* are lazy anyway and never read documentation.
Not really, it's a problem in the linux world imho.
If you take a look at question and answer sites like stackoverflow you will most likely get an answer to things you would think as a beginner question / described in a faq.
For example you have a really good documentation from microsoft for c# (msdn). The documentation does not only show methods etc, but also gives examples. For a lot of people an example is more clear then an abstract description.
On stackoverflow you will find questions like how dictionaries (hashtables for the rest of the world) are used efficiently to get the resulting key/value-pairs in some order. It would be trivial to say: it's unordered, get every element and order them for yourself. Or: read the MSDN. Most likely you will see code for some solutions. You will also get most likely an explaination that .net has specialized dictionaries which can be better used for such a task and if somebody has always used something liek this you will get an explaination that you should not used OrderedDictionary, but SortedDictionary and an example. That is sufficent for the beginner to know. (I personally think nobody knows all classes of such a huge framework and sometimes you will get a better result if you have other people to talk about a problem. Asking a question means to think about the problem. Explaining to others what you want to do is a way to structure a problem. Do you know rubber duck codding/debugging? If you have something you don't now and you seem to be stuck take a rubber duck. Try to explain to the duck the problem you have. In the moment you are beginning to ask the duck a question you are forming the question in a way somebody can understand. In this process it is likely that you get an answer from yourself. (instead of a rubber duck a working student is a good replacement - it doesn't matter if the duck/student can't answer the question. You have thought about it and then know better what you need. Think about a possible answer. Sometimes you see a problem from another site and get a solution. Sometimes you need to search further or find somebody with the knowledge.
If you have something like a sourcecontrol system it is not the thing you want to focus on. It is nice to know a lot of things about let's say git or svn. But it is not the main job. Wading through tons of documentatino for a sidetask is not efficent. If you have a larger organization put the task to somebody who then can be the reference /oracle which can be asked if something needs to be done which is complicated. But normally for most tasks a more simple howto can help. For example i have seen 4-5 pages articles in magiazines which describe things you need to do an a sourcecontrol system on 3-5 pages. And it seems to be sufficent for daily work. Not a ton of things you never need and forget, but a simplified form for somebody just need using it. It's a more practical approach which can be read and adopted in 20 minutes if you are slow (not heise, itwas something linux specific - heise articles only start to explain a problem and in the moment then it starts to get interesting - they stop.)
The thing is: most documentations are written by somebody who does not want to write a documentation, but needs to do. No didactical knowledge, just some facts (like throwing some kitchen junk to pigs to eat it) Documentation is a thing which is outdated quite fast. That is the sole reason why people are wading through documentation - it is most likely not written for somebody to learn something fast or get only the things to know first. If you look at programming books you have a lot of old-style thigns and some which are explicitly written for beginners (e.g. Schrödinger lernt XYZ or XYZ Head To Toe). For some people it is better to learn somethign which such a book (i don't like them, but they take a modern approach using learning theories - somethign you doin't normally find for something liek a source control system). Something like https://rogerdudler.github.io/git-guide/index.de.html will be enough for most starters. http://git-scm.com/book/en/v2 is a bit of overkill. If no questions from starters are asked you will not have a feedback whats wrong with your documentation. Or where things you need to know are not described or linked to descriptions which are sufficent for tasks.
Respect is a two way thing - not onyl going from an asker to somebody asked. Many developers think about as not worth answering.
Best regards Wolfgang