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.
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.
Many other languages I've come across have oddities that pretty much require asking someone who already knows the answer.
(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.
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.)
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.
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.
It's even further increased by being able to read the source, but that's even more costly.