We cannot always rely on a spoon-fed etiquette guide to tell us how to come up with a good question. Sometimes, the best questions are the ones that don’t conform. Or go completely against what the etiquette guide says. So, what’s a good question? In my brief journey through Stack Overflow forums and questions, I have come up with a bit of a theory.
First, let’s get a good sense of a bad question.
There’s not necessarily anything wrong with their formatting. The question is relatively clear. However, by asking how to implement a mathematics calculator in a way in which Jave doesn’t easily operate, the original poster is left downvoted and unanswered. This is an example of someone who does not understand the concepts of the homework they were assigned. They know the outcome that they want, but fundamentally don’t know that the way they are interpreting the language is wrong. Answers provided to help the user didn’t clarify that they had a fundamental misunderstanding, and instead addressed his /her question directly. Answers were given that were convaluded or completely outside of the “3rd day of Java class” scope.
Another question by the same user provided the code that they were trying to fix. The question is how to use the ‘\t’ in order to create a table out of the data provided.
I believe this would be a learning opportunity to place the tabs in different locations and see what the outcome is. The question itself is not high-level debugging, in that messing up where the \t are located, would run very low risk of affecting the integrity or stability of their code. I think that this makes the question come across as someone who just needs their homework done for them. They followed the etiquette guidelines a little better in that they continued to edit the question once they received feedback. However, the answers provided were links to other persons asking the exact same question on the forums. Which probably means that this user did not do that before posting. Another answer to his question was a basic printf. Function table. This is the basic and, I would imagine, the first reference that someone should pursue when looking up the answer. If the user did that, they could’ve mentioned that the instructions were hard to understand , which is common, if you don’t understand the vocabulary used to explain the vocabulary.
If you’re lazy, you end up doing it twice
Again, it has nothing to with etiquette or spaces and fonts. It has everything to do with the honest confusion coming across through the text on the screen. The following two questions are no better worded than those bad questions previously shown. BUT, there’s still a difference.
“How do I delete a Git branch locally and remotely?” More than likely this can be found in a Github FAQ, or even in the users guide for Github. However, the question is worded in a way that is direct, easily searchable, and provides the failed attempts that did not work. This indicates that the user has tried, has done at least some research and is genuinely looking for assistance on an issue.
Another thing that stands out in the directness of the question, and therefore the resulting answers, is the fact that users attempting to answer have to make very few assumptions on how to provide help. For the “bad questions” answering users will start with saying” I’m assuming you’re trying to…” or “I’m assuming you’re doing this on a …” The resultant answers usually deviate from what the original poster actually wanted to get for help. Another reason this question is “good” is because it is so generic. Although counterintuitive, users posting answers are doing so for the different versions of Github and therefore creating longevity to the question and making the availbale answer that much more useful to more and more users as time goes on.
One more example of a good question, which again does not directly conform to the guidelines. It’s a vague question: “How can I remove a specific item from an array in Javascript.” However, the vagueness invites a lot of discussion in terms of the different ways to approach the problem. The constraints that the original poster provided definitely keep other users from making irrational assumptions before providing input. It also helps when there are people posting sarcastic answers and those get shot down by people who recognize this as a legitimate question without a lot of textbook explanation on why Javascript omits certain functionalities.
In conclusion, it’s important to know that your intentions will always come across through the keyboard to the monitor on some other end. If you’re struggling because the answer is too slippery and you need some help, people will help. If you’re struggling because you are lazy, people will know that too. But rather than bring it up, it’ll be up to you to suffer and figure it out.
In Software Engineering, time and efficiency are of the essence. Therefore, if you waste your time being lazy, you will find even more of your time is being wasted trying to correct for that later. If instead, you’ve spent too much time on a problem and just need a fresh look, having a good number of a good set of eyes can make your issue disappear rather quickly and painlessly.