Way higher. Technical documentation is only in rare cases easy to read, whereas SO answers are specifically incentivized to be easily accessible. And any comparison assumes that you can get instantly to the right page of the FM by making a web search, which is far from reality in most cases.
I've tried out many different programming languages in an effort to be able to "read" any language that comes my way (as a security researcher, I've noticed malware authors tend not to write in enterprise Java). The only language I can think of off the top of my head where the manual is the only thing you really need is Lua. I don't know if it's just because it's so tiny or because it's a well-written manual (or both), but it's lucky that this is the case because finding Lua code examples isn't exactly easy.
Many other languages I've come across have oddities that pretty much require asking someone who already knows the answer.
very well put. Both obscure and implicit/obvious information can be very hard to find by just reading the manual.
(Aside from above) I love Python. I only know enough to get by though. I have this program that runs for a really long time, storing the results of each iteration in a dict. These results are complex python objects, and are meant to be processed later on.
Naturally, I tried pickling them. As the file grew, Pickle quickly became cumbersome. It was a bad idea to read and write something that big every iteration. I started wondering if there was some way to write pickle objects incrementally. Then googled it, and an answer from SO led me to the 'shelve' module. It does exactly that, pickling objects incrementally. Its part of Python's standard library. But it didn't turn up on the first page of google's results. It is described in the docs as a 'persistent, dictionary-like object'. Well, if not for SO, I would have been stuck with the wrong set of keywords to search with. So, my point is, even if things ARE in the manual, it takes some effort finding it. And SO does an excellent job of leading you on to the right places in the manual/reference rather than just looking down upon you for not grokking the entire manual.
> Well, if not for SO, I would have been stuck with the wrong set of keywords to search with.
This is precisely the sort of bootstrap problem good tutorials are meant to help you avoid. Learning out of a book is not as satisfying as grabbing an interpreter and some example code and just hacking away, but this is precisely a case where the by-the-book method can save you a lot of time and frustration later on.
Another example of a problem tutorials solve is not knowing what 'tasteful' means in a given language. If you don't know what the language culture considers good taste, you'll beat your head against a wall trying to solve problems tasteful developers don't even have, because you're cutting against the grain.
(Yes, yes, a Real Programmer can write FORTRAN-IV in any language.)
Agreed - Especially when I'm working on some technology where I don't need/want to learn it completely and just can't spare the time, but just need to know a small bit of information to fix some legacy item, or something similar. SO is invaluable there - but I do hate when I'm "that guy".
True but I think people often assume, mistakenly, that SO will have a lower cost than RTFM. A great example is Postgres authentication, there are hundreds if not thousands of questions on this topic on SO, almost all of which would be answered by reading the very concise, very accessible section of the Postgres manual.
Not suggesting there's anything wrong with using SO for this but that the cost of reading the manual for these purposes would actually be far lower.
RTFM definitely does have a cost, and like you say being able to find the simple questions answered on SO and the rest of the family is very useful to a great many people.
My problem is the duplication of those simple questions: people asking the absolute basics having not bothered to try Google or the site's own search function. They know the right keywords, they've got them in their question, and they'd learn more by looking through the existing answers than by asking a very specific question themselves.
Some people aren't there to learn: they are there to get someone to do their homework/job for them. But many genuinely are and I'd like to help those people where I can, especially those who have obviously given some thought beforehand and articulated their attempt at understanding thus far (it is easier to be helpful in these cases: you often don't have to explain everything in detail you can say "it looks like you've got it almost right, the niggly little thing that you are missing in your understanding is..."). And sometimes even the obvious beginners will actually ask a really interesting question.
From the other side: answers that simple say "Do X" but ofer no further word of explanation are worse than a bad question. A good answer will help the questioner and other passers-by learn from the question+answer, an overly terse answer is just handing the man a fish (and not necessarily the right fish). Luckily there are enough good people contributing on most of the stackexchange sites that the bad answers are outnumbered and the voting system works well enough that the good ones float to the top.
I just spent a month getting back into Android development with writing an app. I can't express how many times I knew the answer would be easily findable in the docs but I also knew that by searching on Google it would give me a SO link where it takes about 5-10s to have the answer. While looking it up and reading the SDK documentation would more likely lead to 60-90s with presenting me less information and alternatives.
In fact, it's probably higher than searching SO through Google. This is why I'm hugely in favor of even basic questions getting answers on SO.