Software engineering is a collaborative experience, and in any such setting, communication is of utmost importance. This is particularly apparent in the current work atmosphere as many people have been forced to work remotely, so relaying information both effectively and efficiently has never been more crucial. The ability to ask questions is often overlooked when it comes to communication. Eric Raymond provides a detailed analysis on the art of asking questions in his essay "How To Ask Questions The Smart Way". Raymond lays out a general checklist of concepts to consider when asking questions in a technological environment and provides a number of "good" and "bad" examples. His checklist is particularly applicable in a written format such as emails or team chats, both popular methods of communication in group work.
Here we have an example of a well thought out question on StackOverflow--the programmer's hub for all things necessary.
Upon opening this link, we are presented with a highly organized question that includes some key qualities mentioned in Raymond's essay. First and foremost, the subject title is concise and provides important pieces of information--what they want to do and the language they are using. In this way, just by reading the subject line, you can somewhat expect before opening the full message. In this way, you can also figure out if this is a question you are able to provide assistance with. In the message of this question, instead of simply asking "how do I do 'this'?", the first portion provides a very precise goal with stipulations. They then show their current strategy, the error message, and what they actually want to achieve. Because of this straightfoward message, Because of the straightforwardness and clarity of this proposition, other users were able to offer solutions without having to start a long thread.
Now here we have an example of a question that is not only hard to follow but is also rather vague
While the title of this question is not the worst, it is still difficult to know what to expect as we saw with the previous example. Sure, we can probably guess it has something to do with HTML, but upon further investigation, the HTML portion is only a piece of the problem. We can also note that although the user did include php as a tag for the question, it is not brought up anywhere in the message subject or body. Furthermore, the body of the message then goes directly into four chunks of code with a flustered description beneath them. What stood out most in this description was the blatant self doubt and the phrase "really stupid question". For whatever the reason may be, it is almost natural to want to include a sort of disclaimer when asking for help; I have found myself guilty for doing the same thing. However, Raymond shows how such statements can be inappropriate and even direspectful in a professional setting. Luckily, the issue itself was not complicated and did not require further questioning, so a solution was easily found.
As someone who provides tech support for a job, I know firsthand how important a question can be. What follows the cordial greeting when answering the phone is always a hit or miss. Sometimes it's a well explained issued, but more often than not, it's a vague of string words to be deciphered, which leads to a tedious game of 20 questions to ascertain the situation. This additional step of having to elucidate the issue elongates the process of providing assistance. Now of course we do not expect these users to be experts and asking questions of clarification is a part of this job, but one can at least hope for some basic information besides "I need help with my computer". Many users also add in a disclaimer such as "I'm not tech savvy" or "computers hate me", which can be endearing or invoke empathy most of the time, but in many cases the questions are usually something they could have figured out themselves without needing a tech background. As Raymond stated in his essay, "STFW!". However, I am pretty sure I would be out of a job if that concept was actually put to use.