My life as a computer engineering student is filled with questions; simple ones that I ask myself, complex ones that I ask others about, and weirdly specific ones that I would like to ask but never say out loud in order to not sound ridiculous. At this point it would be cliche to say “there’s no such thing as a dumb question.” Yuck. This is one of the few phrases that I legitimately hate, because I can think of a million different questions that are in fact dumb. Things like “why do meteors always land in craters?” or “why did ancient civilizations build ruins?” are objectively dumb questions (I’ve heard both in my college lectures being asked un-ironically).
But at the same time it would also be cliche to point out this fact without explaining why questions like these are bad. What makes a bad question? What makes a good question? How can we use this to our advantage in our professional lives? Here, I’ll be looking at several different questions from StackOverflow in order to determine what makes a question in software engineering worthwhile.
I find that the best way to learn how to do something is to first observe how not to do it. So let’s look at a fairly bad question and dissect it to see what’s up.
This is from a user who asks the question “How to find the second biggest mode in C” (link).
The output on the standard output the number that occurs with the second highest frequency in the input followed by a newline character. If there are more than one such number, your program should output the highest one. If all numbers in the input file have the same frequency then output 0.
For example, if the input file contains the integers 1, 2, 10, 1, 1, 2, 3, 2 then frequency of 1 in the input file is 3, frequency of 2 is also 3 and frequencies of 10 and 3 is 1 each. Your program should output 10\n in this case.
I finished the sort part , find frequency part, but I do not know how to find the second biggest mode. I attached my find frequency and find second biggest mode code.
I didn’t put in the code that they also included because from this point I would have already stopped reading and moved onto the next question.
But why?
There are a few gut reactions that I get from this question, but the biggest one comes from the fact that this question seems to come from some sort of homework problem that the author did not intend on finishing or really even attempting completely. How do I know this? Because the question is just so vague. 2/3 of the “question” is dedicated to the assignment, and only one sentence is the actual question itself. Maybe this was not the intent and maybe this person really has no idea, but overall this question generally feels like someone asking “I have this homework problem and I kinda tried to do it but not really. Can you guys do it for me instead? kthxbai.”
I can even see that other people feel this way from how hostile some of the answers seem to be. Here’s one of the comments:
And we do not know how to help you unless you ask a specific question. We won't just write the whole thing for you so you need to ask something that will help you make that next step in writing the code yourself.
It seems like there is no initiative, no real internal drive to complete this question from the asker’s end. We would gladly be able to help if we knew what the problem was exactly. Maybe the question could have been, “how should I approach this question”, or “I’m new to C and need help understanding to iterate: can someone help me?”. These aren’t great questions, but they’re at least better. Even though some of the answers can be found easily online, it would at least have shown that the asker took the time to sit down and think about the question, or have shown that they have the drive to complete the question themselves if they knew the general location of where to go.
That’s the problem with these types of questions: they are uninformed questions that are so general as to not have a direct answer.
So, what can we do about this?
Let’s look at another question. This one asks “does avro C implementation support streaming rather than file output?” (link).
I have gone through the C document at avro and I see that I can get only avro output to file. How do I get the serialized output to a buffer so that I can send over a tcp socket. Any help is much appreciated.
This is a much better question.
The question doesn’t feel like a homework problem from my end, and whether or not it is one is irrelevant: the person answering the question shouldn’t feel like the question is a homework problem for them to solve, it should feel like a query that we can provide valuable insight into.
The asker has shown that they have taken to the initiative to read documentation readily available online in order to try and solve the problem themself but has come up shorthanded. The question itself is short and very concise: “How do I get the serialized output to a buffer so that I can send over a tcp socket?”. From there, we can answer the question directly since there is no ambiguity when it comes to what they want exactly, and we even know how we can explain it since the author clearly states that they have read the documentation for avro C. We can provide information that we think can help and direct them to a resources where they can learn more.
Questions are the building blocks of STEM. The whole idea of doing research and science is based off of asking questions, by definition, that’s what a hypothesis is. However, we cannot be productive if our questions aren’t productive themselves.
There’s just no where to go, no jumping off point from that. People become hostile, they feel belittled, and good conversations can cease if we ask bad questions. When we ask questions in software engineering we should really feel like there can be something valuable gained.
As Engineering students, Computer Science students, or anything like that, we have a duty to take responsibility and answer as many questions we can ourselves and seek out those that are truly out of our grasp. Only then can we have more meaningful conversations and cover more interesting topics so that we keep ourselves from asking about really stupid things.
You know, things like “why do meteors always land in craters?”