Differences between revisions 3 and 4
Revision 3 as of 2010-07-12 08:44:00
Size: 4192
Editor: Lhunath
Comment: Bad Question #2
Revision 4 as of 2010-07-12 08:47:06
Size: 4451
Editor: Lhunath
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
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 word around 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. 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.
Line 41: Line 41:

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.

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 correctly, many have even solved their own problem they could not solve before.

Lost in the details

  • After I grep for a word in a file, I need to delete that line and the next 4 lines. Any thoughts?

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.

How do we reformulate this to get the correct answer?

After I find a line in a file that contains a certain pattern, how do I delete it and the next four lines from the file?

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 reasonable to assume that attempt at a solution was flawed and basing your question on it will only mislead either the people that will help you or yourself.

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.

BadQuestions (last edited 2018-11-28 22:17:52 by GreyCat)