There's still time

This scenario is not yet a problem for this site, but we will get there, since it's a huge problem for Stack Overflow

This topic should be separately addressed, too.

At time of writing, the main category here has 673 posts (perhaps a few more deleted ones, because I could have sworn I saw it say 674 before). As long as we're comparing to Stack Overflow, it took them about a week to get that far in private beta. When we're at the size Stack Overflow reached by, say, the start of 2011, I'll be a little more worried about "getting there" and having a "huge problem".

That said: it's all well and good to have a "community-focused" platform, but if the community's goal is to have a really nice, high-quality, public-facing reference library (and I really think that's the most worthwhile goal for a Q&A site), eventually that goal is going to come into conflict with the desire to treat "community" as a warm happy family. Even without such telos, there are natural limits on community formation before friction arises, with ingroup/outgroup dynamics etc. etc.

So at some point, some form of gatekeeping will be necessary. However, tone-setting can forestall a lot of gatekeeping, and works better when it's possible. So if we're going to be proactive, the best way to do that is by asking and answering model questions before the hordes arrive.

With that out of the way:

which they could have easily answered themselves by reading the first chapters of a beginner-level book or by doing a minimum amount of research with a search engine. That is, they did absolutely zero research effort and treats the community as an interactive beginner tutorial, expecting instant gratification by having their FAQ answered.

The problem here is not the ease of answering the question

...or of finding an answer off-site. I'd like to argue here that the reason SO has been successful (to the extent that it has) isn't because there are millions of questions; it's because some of those questions get millions of views. Here are the top ten most viewed. By my reckoning, that is:

• Five questions about Git, at least four of which relate to simple, fundamental tasks that developers will need to worry about all the time. (If someone didn't know how to force overwriting local files with a pull, it wouldn't be too hard to work around that anyway).
• Two JavaScript questions about basic array and string manipulation.
• A question about making hyperlinked buttons in HTML - any reasonable solution is more or less a one-liner, unless you want fine-tuned control with CSS.
• A Python question asking how to list files in a directory; even the most advanced variations on this (filtering the results with custom rules) are not that hard to walk through (pun intended), and the straightforward interpretation of the question is again a one-liner.
• A question about how to use the find command in Linux, although the task is better done with grep. Solutions here are inherently one-liners, because the question is about fixing a one-liner.

None of this is esoteric or complicated. The Stack Overflow answers find ways to write books on interesting, detailed explanations of the mechanics. (The problem is that there are way too many answers, and most of them want to write the same book, redundantly and not as well.)

My point is, questions in general aren't bad because they're easy. These questions are superior because they're easy. And if you decide ahead of time that you don't want the easy questions that everyone needs an answer for... then you don't get millions of views. Period.

(Of course, view counts are absolutely not a measure of quality. But you get the idea.)

The problem here is not the desire for instant gratification

If people find an answer by using a search engine and then finding and reading a Codidact post - mission freaking accomplished, right?

The problem here is not inherently lack of research

Ten years ago, as the rate of new questions on SO was nearing its peak (yes, really. I had a nice SEDE query for this somewhere but I lost track of it) one of their meta site's most infamous Q&As appeared, arguing for the importance of doing research before asking a question. But with the benefit of hindsight, we've learned that being able to find an answer on other sites doesn't make the question of low value. As I said on another post here, we can't make the Internet DRY, we can only make our own site DRY. From the perspective of site utility, it's better that we do have those easily researched questions - and show that we can answer them better than anyone else.

The actual problem is the expectation of interactivity

Speaking of that meta.SO post, the top answer there has an interesting bullet-point list:

• Search. Like mad.
• Test your code.
• Troubleshoot.
• Read blogs.
• Find books.
• Follow tutorials.

The latter three points are just generally educating oneself about programming, so they don't offer a lot of insight here. What I want to highlight is that researching is not just searching; it's privately studying the code. Testing and troubleshooting (i.e. debugging) leads to identifying and isolating problems, so that they can be clearly described and focused on individually - which in turn produces something that other people can search for (as long as they also do the above work). Without that, nothing useful can be produced.

The bad questions on SO mainly don't suck because of being about things that beginners need to know, want to know, or could wonder about. They suck because beginners are asking them, and because beginners are asking them in the context of their own personal struggle, lacking the necessary perspective to ask a good question.

When you let a beginner ask the question, what you get often doesn't make a whole lot of sense. Often multiple entirely unrelated problems are conflated or combined. Sometimes it takes considerable experience to ask about a basic problem correctly. Often it takes experience to notice a pattern (or here, or here...) in how beginners fail, even if it's "a typo", and look for ultimate causes of that failure.

A "good easy" question is one where the refinement has been done up front - so there is no demand for interactivity. Beginners usually don't know how to do that refinement, which is where the bad impression of "beginner questions" really comes from. Worse, the bad questions often get followed up with help vampirism, for basically all the same reasons that led the question to be bad in the first place.

How and Why

My mental model of technical Q&A sites breaks almost all of the objective questions into two categories:

• How do I do X?
• Why did X happen (instead of Y) when I did Z?

With beginners, the why-questions usually cause more problems. All the "please debug my code" questions fall into this category, and they get asked way more often than "please explain this dump of someone else's code" (though this can also generally be recast as a why-question). Finding someone else's bug usually isn't fun, and it rarely-to-never results in the ability to help a third party. If we're going to take those on at all, we really need a separate Debugging category for them, as discussed in comments on another answer here.

When easy how-questions suck, usually it's because they're a "please do my homework" question. Those are a lot easier to deal with, because they'll naturally break down into a logical series of steps, and then it's easy to point at whatever policy and ask someone to ask separate questions instead. From the perspective of the site, if the same homework assignment leads the same person to ask multiple, clear, non-duplicate questions - is there really a good reason to object?

The other main problem with how-questions is when the specification is unclear or ambiguous. Sometimes it can be hard to realize the existence of corner cases, or even just slightly interesting cases where it isn't immediately obvious what the output should be. But usually this is a sign that the question isn't really that easy anyway.

Looking at the current off-topic categorization:

• Asking for implementations of a certain feature or a whole homework assignment. You should include your (partially working) attempts in the post
• Asking for detailed explanations of posted code, unless the code is small, self-contained, and an attempt to understand it is also included.

That is: how-questions that want to do multiple things, and why-questions that require explaining multiple aspects or considering a bunch of irrelevancies.

Either way, that is what SO currently calls "Needs More Focus".

posted over 1 year ago

CC BY-SA 4.0

Karl Knechtel‭

2175 reputation 39 54 280 85