Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.
Half the fun on Stack Overflow is the endless use of closed-ended
questions. "Can I do this in Python?" being so common and so hilarious.
The answer is "Yes." You can do it.
Perhaps that's not the question they really meant to ask.
Closed-Ended Questions have short answers, essentially yes or no. Leading Questions
and presuming questions are common variations on this theme. A
closed-ended question is sometimes called "dichotomous" because there
are only two choices. They can also be called "saturated", possibly
because all the possible answers are laid out in the question.
The most important part about asking questions is to go through a few steps of preparation.
Use Google, use the Stack Overflow search. A huge number of people
seem to bang questions into Stack Overflow without taking the time to
see if it's been asked (and answered) already.
- Define Your Goal.
Seriously. Write down your objective. In words. Be sure the goal
includes an active-voice verb -- something you want to be able to do.
If you want to be able to write code, write down the words "I want to
write code for [X]". If you want to be able to tell the difference
between two nearly identical things, write down the words "I want to
distinguish [Y] from [Z]". When in doubt, use active voice verbs to
write down the thing you want to do. Focus on actions you want to take.
- Frame Your Question. Rewrite your goal into a sentence
by changing the fewest words. 90% of the time, you'll switch "I want
to" to "How do I". The rest of the time, you'll have to think for a
moment because your goal didn't make sense. If your goal is not an
active-voice verb phrase (something you want to do) then you'll have trouble with the rewrite.
In some cases, folks will skip one or more steps. Hilarity Ensues.
form of closed-ended question is the veiled complaint. "Why doesn't
Python do [X] the way Perl/PHP/Haskell/Java/C# does it?"
this is "my favorite other language has a feature Python is missing."
The question boils down to, "Why is [Y] not like [Z]?" Often it's
qualified by some feature, but the question is the same: "Regarding [X],
why is Python not like language [Z]?"
The answer is "Because they're different." The two languages are not the same, that's why there's a difference.
leads to "probing" questions of no real value. "Why did Python
designers decide to leave out [X]" and other variants on this theme.
the answer was "Because they're evil gnomes" what does it matter? If
the answer was "because it's inefficient" how does that help? Feature
[X] is still missing, and all the "why?" questions won't really help add
it back into the language.
It's possible that
there's a legitimate question hidden under the invective. It might be
"How do I implement [X] in Python? For examples, see
Perl/PHP/Haskell/Java/C#." Notice that this question is transformed
into an active-voice verb: "implement".
look at the three-step question approach above, there's no active-voice
verb behind a "why question". What you "know" isn't really all that
easy to provide answers for. Knowledge is simply hard to provide.
Questions about what you want to do, are much, much easier to answer.
One other category are the "questions" that post a pile of details looking for confirmation. There are three common variations.
The wealth of detail was overwhelming. I'm a big fan of the "detail
beat-down". It seems like some folks don't need to summarize. There
appear to be people with massive brains that don't need models,
abstractions or summaries, but are perfectly capable of coping with
endless details. It would be helpful if these folks could "write down"
to those of us with small brains who need summaries.
question at all, or the question is a closed-ended "Do you agree?" An
answer of "No." is probably not what they wanted. But what can you do?
That's all they asked for.
- Sometimes the question is "Any
comments?" This often stems from having no clear goal. Generally, if
you've done a lot of research and you simply want confirmation, there's
no question there. If you've got doubts, that means you need to do
something to correct the problems.
Here's what is really important with tl;dr questions: What do you want to do?
of the time, it's "Fix my big, complex tl;dr proposal to correct
problem [X]." [X] could be "security" or "deadlock" or "patent
infringement" or "cost overrun" or "testability".
Here's how to adjust this question from something difficult to answer to something good.
You want to know if your tl;dr proposal have problem [X]. You're really looking for confirmation
that your tl;dr proposal is free from problem [X]. This is something
you want to know -- but knowledge is not a great goal. It's too hard to
guess what you don't know; lots of answers can provide almost the right information.
Reframe your goal: drop knowledge and switch to action. What do you want to do? You want to show that your tl;dr proposal is free from problem [X]. So ask that: "How do I show my tl;dr proposal is free from problem [X]?"
you write that down, you now have to focus your tl;dr proposal to get
the answer to this question. In many cases, you can pare things down to
some relevant parts that can shown to be free from problem [X]. In
most cases, you'll uncover the problem on your own. In other cases,
you've got a good open-ended question to start a useful conversation
that will give you something you can do.
The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!