Muad'Dib learned rapidly because his first training was in how to learn. And the first lesson of all was the basic trust that he could learn. It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult. Muad'Dib knew that every experience carries its lesson.
– Dune, Frank Herbert
The value of questions
Why this text
This text addresses a fundamental point: the critical exploration of the self in the context of the critical exploration of the world. This text aims to shed some light on the matter by expanding on a simple idea: the process that leads to asking a question.
Why ask a question
When my father was a teenager, in the late fifties, his science teacher used to ask the following question:
If we had a machine that could give you the answer to any question you had, would there be any point in doing science?
And here is the answer this same teacher gave:
Yes! Because the point of science is to ask questions. The answers are just the work.
This is a very important idea. Sure, science put dogs and people in space, but the only reason this became possible was because people asked the questions that led us to this result.
What comprises a question
Part 1: asking the question
In order to ask the question, you have to evaluate the situation and understand what is not clear sufficiently to word it. This exercise is very valuable, as it trains you to recognize situations and problems. Being mindful of what you do as you do it is very helpful, as it shortens the evaluation time. It is usually equally important to be mindful of why you do what you do, as knowing the goal can help frame your question.
Part 2: getting the answer
Knowing the answer means at the very least that now the question is out of the way. With luck, it was the correct question, and now we can proceed to other interesting ideas and problems. Otherwise, one must endeavor to find another, better question, closer to what the actual problem is.
Where we stand
Being a developer means crystallizing a vague problem that people have into a concrete set of behaviors which distil down to a solution. Being a developer means being able to think, connecting ideas and questions into patterns old and new. Learning to code is just learning to put characters next to each other. Eventually, even monkeys can write Shakespeare. Typing the code is irrelevant; writing code does not a developer make. Code is just the byproduct of the mental process that leads you to the choices of behaviors you are implementing. What you are truly learning to do is learning to ask questions – and work your way to the answer. Every single time you don't practice asking a question, you are robbing yourself of what you came here to do.
The work of asking the right question is not optional. You have to do it, because it will be your constant companion in the future.
Unfortunately, this is not a History or Geography course. The topics we discuss and teach aren't simple matters of memorization, and the questions are rarely as simple as "I forget where Zimbabwe is". They usually are more like "I'm trying to get this particular set of data out of my storage layer and transform it into such a way that it is available for presentation with a simple each loop when I go to this URL, but SOMETHING IS GOING WRONG"
Sometimes, saying "help" means "I'm really confused by what is happening, I am at my wits' end and I need someone to help me re-center so I can continue doing the work"
When that's the case, please explain that out in the way which is appropriate for your current situation. This will help us understand the context, the words, and the question.
The human aspect of questions
When you want someone to answer a question, a few things need to happen:
- They have to understand your context
- They have to understand your words
- It has to be the right question
Let's go through a few examples and examine how they fit the criteria:
"help, issues running a ruby file"
The context is clear: we're trying to run a Ruby file. The words are clear - a file isn't working. The question is unclear, because there are many, many possible reasons for a Ruby file to not work.
"help with homework"
The context is unclear. Which homework? The words are clear - it's got to do with homework. The question ... Well, it's not a question.
"help cant run server on p80"
The context is unclear: why can you not run the server? The words are clear: we want to run a server on port 80 and we're unable to. The question is unclear: do we want to know how to do it or why it doesn't work?
"help Bookmark App -- Refactoring Timestamp code"
The context is clear: the timestamp code of the Bookmark application. The words are clear: we want to refactor existing code. The question is unclear, but that's probably because how to refactor is usually a nebulous question.
"help understanding where this logo is supposed to go in the "brook and lyn" assignment"
The context is clear: the "book and lyn" assignment. The words are clear, there's a question about the design. The question is unclear - "this logo" is pretty dependent on what the person asking the question is thinking about at the time.
"help "Remote Host Identification has changed""
This is an interesting example, because it is simply an error message. However, here's the thing: The context is clear. This error message means one thing and one thing only, and has a particular context attached with it. The words are inexistent. The question is also inexistent, but we assume whoever posted this got stumped.
"help with SyntaxError in circle.rb - line 4 is empty and I can't figure out what's wrong"
The context is clear - the file
circle.rb has a SyntaxError on line 4. The words indicate that the person has read the error message and tried to figure it out. The question is "I'm out of ideas, I don't know what's wrong".
I'm sure by now you can see where this fails to meet the standard.
- The inspiration for this document, "How to ask questions the smart way" is an excellent read
- A debugging checklist
- How to queue yourself for help
- The scientifc method of troubleshooting (GoGaRuCo 2014)