Post History

Giving a fish vs. teaching how to fish

On any Q/A site, or even analogous media like support forums, there is a dichotomy between "asking for a fish"[1] questions and "learning to fish questions"[2].

*Teaching how to fish* is usually more exciting for fishing experts. Many people consider it a more "pure" knowledge. The answers to this type of questions evolve slower, so they are more durable. In some cases, I've seen moderators and regulars of sites (not necessarily just this one) push back heavily on people asking for a fish.

It's easy to point out the problems with asking for a fish: There are potentially infinitely many variants. Answering all of them is not feasible. If you attempt it, your coverage (answered questions / all possible questions) will always be tiny, so it is unlikely users will ever find that their question has been answered - they will almost always have to ask a new one. Meanwhile, for answerers, many questions are just reskins of each other, they're boring to answer over and over, so the whole business is demotivating. *You will never feed the world by giving a fish to everyone who is hungry.*

My claim here is that it is a mistake to ban asking for a fish entirely. However, by answering such questions we should not aim to be a comprehensive catalog or encyclopedia of every possible specific question that could come up. Instead, the "asking for a fish" questions should be treated as illustrative examples or selected case studies. After the fish has been handed out, *the ball is in the experts' court* to extract some general lesson from it about *how to fish*, and write it up as a *learning to fish* question (likely with a self-answer).

But meanwhile, the fishes should continue to be handed out, for two reasons:

* It grows the community. Newbies coming to ask for a fish drives traffic to the site. Many an expert is a newbie who was given one fish too many, and ended up connecting the dots. (i.e. topics are often mastered inductively, rather than deductively)
* It helps the experts. General principles about how to fish are easier to establish if you examine concrete examples rather than always staying abstract. (i.e. knowledge is often acquired inductively, rather than deductively)

To restate in sum, IMO the following are the elements of "best policy" for a QA site on the topic of "fishing":

1. Questions asking for a fish are okay. People asking them should not be scolded. Experts should make an effort to answer them.
2. When you give someone a fish, you are not done. You should always do a follow up step: Consider whether you can contribute to a "learning to fish" question with what you learned from the fish you just gave out.
3. Fish go stale. Asking for a fish questions are unlikely to maintain relevance years into the future, especially if you follow 2 and link back to your "how to fish" question from the original ask for a fish. The community need not worry about what % of asking for a fish questions are covered, and the "reusability" of such questions. This means that low quality is acceptable when asking for a fish, so long as it clear what is being asked. The "real" answer will be preserved in a new "learning to fish" question anyway. In other words, diversity and quality of "how to fish" questions are KPIs for a QA site. Quality of questions asking for a fish is not a KPI. Diversity of past answered asking for a fish questions is also not a KPI. But number of asking for a fish questions *answered per month* **is** a KPI, because it supports the "how to fish" KPIs.

That said, for organization's sake, it seems like it would make sense for every Codidact site to have at least two sections: One for questions about how to fish, with stringent rules on content quality. And a second for questions asking for a fish, where quality is not too important, and the section mainly exists to feed the first one, and is otherwise ignored. As an important example, closing a question for being "too localized" would be very normal in the first section, and not applicable in the second.

When you are trying to build a healthy community of experts sharing knowledge with non-experts, the interesting activity is "learning to fish". However, there must be a second, parallel activity of "handing out fish", because without it the community is stymied. (I am deliberately glossing over the reasons for this).

-----

I'm putting this at the end because I think it will be obvious to most, but for clarity:

[1]: "Asking for a fish" refers to questions that ask for help for a very specific thing. For example, a certain bug that happens in a certain program, a specific issue that shows up when trying to run a program on a certain configuration, asking for a solution that applies to a specific problem. At face value, these questions are such that it seems unlikely anyone will encounter the same exact problem again. I've heard some people call these "helpdesk questions".

[2]: "Learning to fish" refers to questions about general problem solving skills. For example, general principles, debugging strategies, common Linux troubleshooting advice, best practices for a type of project. These questions are such that when you learn the answer to one of them, you can apply it to solve any one of infinitely many variants of an "asking for a fish" question from a certain class.