Early and “where to start” questions
I already discussed how Stack Overflow encourages laziness and how most performance questions are wrong. The more I focus on the questions asked by my peers, the more I notice how incomplete, raw and unconstructive they are most of the time. Either people are lazy or they don't know how to work on problems by themselves; in both cases, it is unclear what are they expecting from others.
It's usually the same thing: either the person asked the question too early, or he just doesn't know where to start.
Early questions
“There are no stupid questions”—teachers tell. Maybe, but there are questions asked too early.
In order to be constructive and answerable, the question should we elaborated. Often, elaboration itself leads to the discovery of the answer. If not, a correctly-elaborated question is usually pleasant to answer and brings something to both the asker and the answerer.
The following dialogue happened today on a discussion opened to all company developers:
- Mike
- Does somebody know OpenGraph? Help me.
- Jeff
- Isn't it a Facebook API similar to Google's Knowledge Graph?
- Mike
- Yes, it's related to Facebook...
- Jeff
- See Open Graph protocol, and Facebook's documentation.
- Mike
- I know what is it for, but I don't know how to add it to an ASP.NET MVC site.
This is an archetype of a question asked too soon, obviously lacking any effort and prior work. Not only Mike haven't worked on the problem itself, it seems that he haven't even made an effort to formulate the actual question. Why would he ask something like “Does somebody know OpenGraph?” while he needs something much more specific?
This is what happens when the asker didn't thought about the question. A few sentences exchanged between the asker and another person are enough to pinpoint the actual problem. This process doesn't necessitate a third person: the author of the question could do the same work alone, without immediately seeking for assistance.
Some questions are too generic, and some are too specific. When facing those questions, it is essential to understand that both cases are not that different, and the fact that too specific questions look more elaborated is just an impression.
A too generic question can look like this:
I have an error which complains about my file when I open it in Microsoft Word. Please help.
Questions about errors which don't specify the error itself and show that the person probably didn't even make the effort reading the error message are always generic-type early questions.
A too specific question can look like this:
- Mary
- I don't understand how to use an abstract factory pattern here, can you help me?
- Vanessa
- Sure. What do you need to do?
- Mary
- I need to create business objects from database entities, but all objects look different. If there is nothing in common, how should an abstract factory look like?
- Vanessa
- Wait, what?! Can you give me an example of an object to create, please?
- Mary
- Sure. I have a
Newsobject, which should containDateandBody, and I have an SQL query which returns those fields, but I don't know how to use an abstract factory pattern to createNewsobject. - Vanessa
- You are trying to create a
Newsobject in data access layer, right? Probably in aNewsProviderclass, something like this... - Mary
- I am.
- Vanessa
- Why can't you simply initialize your `News` objects there?
- Mary
- I believe I can do that. Thank you for your help!
- Vanessa
- You are welcome.
They are born in a context where the author asks them too soon, without thinking a bit about the actual problem. They are often based on the first idea the author thought of (like the willingness to know more about OpenGraph or the association between creating objects and the usage of a factory pattern).
The succession of questions and answers show very quickly the lack of prior thought about the problem and often highlight the problem itself.
The question can be answered as-is, but the answer won't help the author of the question. In the first example, the answer consists of the RTFM in a form of two links to the documentation. In the second example, the answer would be the actual implementation of an abstract factory pattern in a specific case, without considering how absurd would it be there.
Both too generic and too specific questions share several elements:
When faced with those questions, lead the author to the understanding that he needs to work more on his questions in the future.
Where to start questions
Those questions are more difficult to answer, for two reasons: you need to know the profile of the person asking the question and you need to figure out what are the actual intentions of the person.
What makes them difficult is also the number of forms they can take.
I don't understand pointers. Could you explain them to me, please?
or:
I want to learn Java. Do you have anything to recommend?
or:
I'm wondering what pattern should I use here...
are all requiring you, the answerer, to do all the work of elucidation of the actual problem or need the askerer is facing. This makes those questions close to early questions, the difference being the scope. In early questions, there is not much to do: you show to the person that the question is either too general or starts on a wrong premise, and then let the person on her own. Where to start questions, on the other hand, require much more work: you have to actually determine the context, the problem and the motive. Is the person looking to learn Java because she wants to learn a new language? Or because she needs to work on a Java-related project? Or because she is expected to modify JavaScript code and mistakenly call the language Java?
I'm not sure how should such questions be addressed, and do they need to be addressed in the first place. One thing is sure: the person asking those questions should be encouraged to reconsider the question, think twice, search about the subject, and ask another question only when the question is actually constructive and answerable.