Post History

Handling common wrong approaches and misguided motivations for basic technique questions

## Background

This is inspired to some extent by https://software.codidact.com/posts/289597 .

I'm trying to provide a large amount of content (gradually!) that novices (mainly to Python) will find useful. The goal of the actual content is to demonstrate standard techniques and clear up common misconceptions; the primary goal of having the Q&A is to anticipate future lower-quality questions (people who actually have these problems are unlikely to be able to explain them clearly, or with correct terminology, or with proper scoping).

In my view, the overwhelming majority of useful questions for a technical Q&A site fall into two categories: "Why (does this attempt have an undesired result)?" and "How (do I accomplish some elementary, well-defined task)?". This meta post is about the latter category, and I have two main issues I want to settle.

## Why/how coupling

In many cases, there is an "obvious" but wrong answer (or a few such answers) for a "why" question. "In the wild", this often presents as someone explicitly stating a "why" question, but then framing and phrasing everything else as seeking debugging help.

From prior experience, it gets really annoying to try to fix up those questions, or close them as unclear or unfocused, etc. when it's already obvious that "oh, it's THIS issue again". Often people refer to this as a "gotcha"; but from the meta perspective, I think it's more useful to think in terms of how a "why question" and "how question" are *coupled*.

Obviously we would like to be able to close such questions as duplicates. But **how do we present the canonicals**? It seems clear enough that a "how" canonical will always be useful, but after that I'm quite indecisive. Should we:

1. Write a separate "why" question for each common non-working attempt and have an answer that explains why it doesn't work and then links to the corresponding "how" question? (I can see this causing problems if the reason it doesn't work is really just an example of some *other* common problem)

1. The same, but putting the question cross-link in a footnote to the question instead?

1. Just have the one "how" question, and let anyone who answers decide about mentioning non-working attempts "in stride"? (If I'm posting them self-answered and this is the preferred approach, I would almost always decide in favour of inclusion.)

1. Just have one question, and use a separate answer (or separate answers) to call out and explain common attempts that don't work (even if these aren't technically "answering" the "how" question)?

1. Just have one question, and include examples of common non-working attempts in the question (just showing what happens, without trying to explain it)?

1. Something else I haven't thought of?

## The XY problem

Experienced programmers should be familiar with this, but, for reference: https://xyproblem.info/. (I'll keep the convention that X is the "real problem" and Y is the approach taken by the person seeking help). Typically what happens is that someone fails at Y and *usually* asks a "why" question about Y, although a "how" question is certainly possible. This is *different from* why/how coupling in that *even if* the question about Y is resolved, it results in a sub-optimal (and possibly dangerous) solution to X.

On the one hand, the mindset of detecting XY problems really applies to help-desk environments more than Q&A environments. *In theory*, a question shouldn't have to justify being asked, as long as it is on topic and properly asked. If you never allow people to ask about Y because they're constantly suspected of actually caring about X, then you don't end up with a Y Q&A; and **if you've excluded questions** *a priori* then by definition the result **cannot be comprehensive**.

On the other hand, people with an XY problem **often can't be expected to recognize** that fact. Even as an expert, the transition from needing X done to debugging Y can be so seamless that one doesn't even have the perspective to realize it has happened. And the **consequences can be dire** - for example, if you only know that an "SQL query" is a string that will be passed from your program to a query engine, and that it needs to include certain pieces of information in order (and that some of those pieces come from the user), then focusing on the problem of creating the string can end up costing a real business huge amounts of money.

So, should we:

1. Ignore the consequences as not being our problem?

1. Write a separate answer to contain such important caveats and anticipate common Xs underlying the Y in the question?

1. Add a caveat to a canonical answer, or separately to multiple answers?

1. Leave it up to everyone who is answering to decide?

1. Add a warning to the **question** instead, perhaps under a fold?

1. Something else I haven't thought of?