[EnglishFrontPage] [TitleIndex] [WordIndex

1. Bad Questions

When people approach others for advice or help in solving a problem, they often find they have a hard time getting the answer they are looking for.

In almost all cases, the cause for this is bad questions. Bad questions don't do anyone any good. It wastes your time, and it means people will be far less likely to even try to help you.

In your best interest, and that of the people willingly offering their advice and experience, here's a few examples of ways questions can go wrong, why they are bad, and how to reformulate them. That way, you will learn to get the correct answers to your questions quickly.

In fact, it is often the case that while giving some thought as to how to formulate your question correcty, many have even solved their own problem they could not solve before.

1.1. Lost in the details

The problem here is that this person is trying to put together some of his knowledge to achieve a goal, but doesn't realize that what he knows doesn't actually apply. You cannot edit a file just from the output of a grep operation on it. You're not in the file, you just have a string of characters that represents a line of text that is copied from the file. The real answer here is to use a file editor, such as ed.

The person asking the question has, for whatever reason, become fixated on grep, to the extent that it's become part of the question. This blinds him to other possibilities that don't involve grep.

How do we reformulate this to get the correct answer?

Why is this more correct? We actually formulate what we want, not how we think to solve it. When you have a problem, always express the problem, not your attempt at a solution. Your attempt at a solution failed; therefore, it is very likely that attempt at a solution was flawed. Basing your question on it will only mislead you and the people trying to help you.

1.2. Help me fix my solution to my problem

It's great when people have tried their best to solve their problems before coming for help. Only, it's important to realize that when you come for help, it's better to explain the real underlying issue you're trying to solve.

Many times, we get incredibly weird questions, asking for things that one should never want to do. Other times, it's quite apparent that the person is trying to solve a problem by means of an ugly workaround or hack. We can help you fix your hack, but that wouldn't be ideal. In almost all of these cases, solving the real problem is significantly easier and in the end, for the person with the problem, it is always the most helpful kind of help.

Annoyingly, this type of bad question is often only identified after interrogation. That's bad, because it means the person will only receive good help if the person helping him is willing to figure out what the real problem is. If nobody is helpful enough to do that, the person with the problem will just get really bad solutions to possibly trivial problems. Consider:

10:24|      Milos | Can someone give me a good example of what I should use to encode something and be able to decode it? i.e. two-way encryption/decryption?
10:24|    lhunath | coding or crypting?
10:24|    lhunath | openssl probably.
10:25|      Milos | lhunath, uh, well, no I think I phrased that wrong - I just want something so I can have "hello this has spaces and *2384" into something like 0938reksfoiur9owe8gi but to be able to decode it afterwards.
10:25|    lhunath | purpose?
10:25|      Milos | lhunath, passing args that might have spaces or special chars.

The real problem is related to using bash parameters to pass data to other programs. Properly quoting the parameters when used as arguments or passing the data in another safe way was the real solution. Encoding the argument data into something else is a horrid way of avoiding bash wordsplitting (instead of turning it off with quoting) and in this case, the person was injecting the data into another interpreter's code. Injecting data into code is always a really bad idea.

So remember: You can ask your question; but also explain your purpose. The real problem you're trying to solve or the actual thing you're trying to do. Explain it without using ANY implementation details; no bash, no pseudocode, just English.

1.3. Questions containing errors

<I440r> in /etc/bashrc how can i modify PROMPT_COMMAND so taht it does not truncate the display of PWD ?

When faced with a question like this, we can't even answer it, because it contains so many errors -- factual errors, conceptual errors -- that before we can even attempt to get to the root of the issue and provide help, we have to deconstruct an entirely erroneous worldview first.

This is frustrating for us, but it's often painful for the person asking the question. Nobody likes to face the fact that their entire perception of reality is wrong. This means that quite often any attempt to help the person is going to lead to flaming (usually in both directions), etc.

In fact, IRC is a very poor medium for addressing perceptual anomalies of this magnitude. One needs time and room to set forth a clear list of the errors, and to address each error separately. This can be done much more easily on a mailing list, or a web forum, or Usenet.

Using our example,

This is just one example. The problem of questions containing errors is quite prevalent and shows up extremely frequently.

2012-07-01 04:05