
Effective communication is an essential skill that all software engineers must have in order to be successful, and understanding how to ask “smart” questions plays a critical role in this process. Eric Raymond’s essay, How to Ask Questions the Smart Way, highlights the qualities of a “smart” question while warning us of the dangers of asking questions that lack substance. For software engineers, mastering the art of asking questions not only improves their own problem-solving abilities but also helps to create a collaborative environment. This essay will discuss the difference in structure and content between “smart” and “not smart” questions. Additionally, the consequences that result from a poorly asked question. We will examine real examples of “smart” and “not smart” questions from the open-source software community StackOverflow, then analyze what makes the questions “smart” and vice versa. Through these examples, we will observe how adherence to Raymond’s guidelines leads to more productive discussions and efficient problem resolution, while ignoring these guidelines results in confusion and frustration.
Before even considering asking a question, a software engineer should try to find the answer on their own so they can enhance their question-asking ability. Whether that be through searching the internet, reading an FAQ, inspecting/experimenting with the code, etc. Additionally, the software engineer should target the correct forum to where they can ask their question. Once that is complete, we can begin formulating our questions. “Smart” questions describe the symptoms of the problem clearly, the environment it takes place in(OS or machine), the research you did to try to solve the issue, the diagnostic steps you took to try and solve the problem, and any relevant recent changes in your computers or software configurations(Raymond).
The importance of asking a “smart” question not only helps the developer take their question to a new level, but encourages the help of others who view the question. A poorly asked question such as “Help, my server is unable to make external connections and I don’t know why” will not yield much help from the open-source community. Not only does the question lack substance so developers have limited data to go off of, but it is also a turn-off to those who sacrifice their time to help people who are having issues. Most of the time, the question will get tossed out or ignored by the community. In order to receive help, you must help yourself and self-discover the issue as much as possible, then explicitly state your issues and the “smart” qualities that surround it. Now that we know what a “smart” question is, let’s look at examples of “smart” and “not smart” questions.
This first question is an example of a “smart” question as it fills the qualifications stated by Raymond. The heading states “Log4j2 does not load custom ConsoleLogConverter and SocketLogResolverFactor plugins”. The issue is then further explained under the header where the user goes deeper into the problem and informs the reader on the environment. Under this portion, the user adds a list of things that he/she has tried, then adds snippets of terminal output logs and code snippets for the reader to see. Here, the user demonstrates the qualities of a “smart” question, and now hackers, as referred to by Raymond, will be able to assist this user and hopefully solve his problem.
Now, lets look at an example of a “not smart” question. The title of this question is “Why is my UIGestureRecognizer code not working?”. The user follows up with “why is this code not working?”, then adds a snippet of code for the reader. This is an example of a “not smart” question because of the lack of substance. The user expects the reader to figure it out all by themselves. It also gives off the impression that the user did not try to solve the issue him/herself. The user found an issue, took a screenshot, and then posted it on stack overflow. Hackers will see a post like this and from the start, be discouraged to help this user. Additionally, there is not much substance or information to go off of. It makes it that much harder to help this user solve his/her problem.
After analyzing these two examples of questions, we can see how more in-depth the “smart” question was over the “not smart” question. These examples clearly illustrate that asking “smart” questions is essential for any software engineer seeking timely and effective assistance. Questions that follow Eric Raymond’s guidelines will attract positive attention, give the reader enough information to offer a solution, and hopefully help solve the overall issue. On the other hand, poorly framed questions often lead to either unhelpful answers or none at all, ultimately prolonging the problem-solving process.