
How to ask good questions - ingve
https://jvns.ca/blog/good-questions/
======
Waterluvian
Having suffered severely from impostor syndrome for a few years, I caught
myself asking a lot of really useless advanced questions that made me
feel/look smart, and ignore the simpler but useful questions.

I was afraid that I would spill the beans on being a fraud who had no idea
what he was doing, so I'd pretend that of course we'll use library X to write
algorithm Y, but then bring up unnecessary complexity about implementation
details.

One significant transition I made as I started to feel valuable and deserving
of my position was to stop asking stupid questions and start asking simple
questions.

------
danso
> _Do some research_

To me, doing research is the lowest hanging fruit with the highest return on
investment. From a journalism context, I push students to hit LexisNexis and
Google hard before they do interviews. Whenever a student complains that they
don't have any interesting questions to ask, or the subject had nothing
interesting to say, almost always the problem could have been mitigated with
pre-interview research.

The benefits of doing research for interviewing:

\- You can learn the boilerplate of the subject, which serves the dual purpose
of making you more nimble in interpreting the context of responses and saves
you from wasting valuable question time of basic info ("So when did you start
directing, Mr. Tarantino?)

\- You can learn the current or ongoing controversies of a subject, from which
almost all interesting questions arise.

\- You find other interesting people to interview.

When your questions are derived from research, you save time by cutting
through the boilerplate and any bullshit that might be offered as a response.
Furthermore, there's an unquantifiable benefit in increasing _respect_ \--
that is, your subject will give you more serious, thoughtful answers because
they see that you've put serious, thoughtful effort into understanding them.

You can gain this rapport if you're in a position of authority, or have the
chance of multiple interviews. But in cases where you're just another
possibly-threatening interrogator, doing your research is an easy and
accessible way of increasing your authority, and thus, the quality of answers
you receive. It can more than make up for in-person skills, depending on the
situation and subject.

Edit: the OP suggests not being so strict on Gogling-before-asking, because
she likes to ask basic questions during casual conversation, like over
lunch/coffee. I think you can have your cake and eat it too. Sometimes I'll
ask questions that I already know the answer to, as an icebreaker. But again,
this requires research for the domain knowledge. Ideally, you want your
icebreaker questions to be one that you anticipate the person is enthusiastic
to answer. While they're saying what you think they'll say, you can spend that
time gauging the person's mood and think of segues into other lines of
questioning. Of course, once in awhile, they'll respond to your softball basic
question with something that you didn't expect...and that in itself leads to
potential insights.

~~~
LoSboccacc
as a an usual question answerer, people that come at me without doing basic
google research pisses me off to no end and I get super unhelpful if I have to
start the explanation from the ice age forward, especially if I'm not in a
teaching settings.

~~~
logicallee
I'm going to completely disagree with you. I've always (WITHOUT EXCEPTION)
learned valuable information when I've _chosen_ to ask a basic questions I
could have Googled. There is a _reason_ people choose to answer it.

Here is a typical basic question anyone could Google: "Could you explain the
difference between C-style and C++-style arrays."

I guarantee you that the answer is better than the Google search.

Now let me search:
[https://www.google.com/search?q=difference+between+C-style+a...](https://www.google.com/search?q=difference+between+C-style+and+C%2B%2B-style+arrays)

Yep. NOT ONE of the search hresults (I opened about 10) explains what they
are, easily.

As a quick test, go ahead and ask your coworkers "Could you explain the
difference between C-style and C++-style arrays." They are a hundred times
more likely to give you better answers.

I thought I would be downvoted for this comment so I went ahead and got on
IRC. This is the answer I received: hi - could you explain the difference
between C-style and C++-style arrays?

<[respondent]> C-array is just a pointer to a bunch of values you hopefully
know the count of <[respondent]> C++ std::array thing iirc has more type
safety

That summarizes EVERYTHING. That's literally it. The key, key, key thing "you
hopefully know the count of" comes FIRST. It's just a pointer. You hopefully
know the count.

And then it mentions that this is information which std::array can track.

That's it. Try to find anything like those two lines out of all of the links.
As far as UNDERSTANDING - as in, if there's a conceptual hurdle, you will
never EVER get as easy and quick an understanding as if you ASK someone. NEVER
EVER EVER.

~~~
LoSboccacc
also, I've to add this is an extremely bad question to google (not in general)

"Could you explain the difference between C-style and C++-style arrays"

to solve it with googling you need instead two searches (c array definition
and implementation / c++ array definition and implementation) plus
considerable brainpower to derive the difference.

what you're asking is thus not a piece of arcane knowledge, but involves a lot
of thinking for the answerer.

a good question to ask would be 'where do I find a complete specification of
c++ arrays?' \- I'd be perfectly happy to sharing resources and even help
searching, because it shows you're willing to put in the work to understand
yourself instead of relying on someone else to do the differential analysis
for you and spoon feed you the results

~~~
cben
This specific question formulation suffers from too vague terminology. If you
asked me, I wouldn't even be sure what "C++-style arrays" means. IMHO, the
most important part of the (imprecise) answer about "pointer vs std::array"
was saying "std::array". Just googling that, immediately gives several results
that all talk about "decaying to a pointer".

"Because std::array doesn’t decay to a pointer when passed to a function, the
size() function will work even if you call it from within a function:"

That's golden. It doesn't fully explain the C pointer/array differences, but
it points out their fundamental problem.

Anyway it's not a good example of question requiring a lot of thinking. It
_is_ standard knowledge for people involved with C++, so could be a very
effective thing to ask someone more experienced, except it's so basic that
googling it I currently get a good SO answer on first place:
[https://stackoverflow.com/questions/7129717/what-does-c-
styl...](https://stackoverflow.com/questions/7129717/what-does-c-style-array-
mean-and-how-does-it-differ-from-stdarray-c-style)

I strongly disagree only people who read the fine "complete specification"
have done their homework. Yes, interrupting coworkers is problematic and
doesn't scale, but stackoverflow does (and IRC etc are not bad). I adopting
Julia's post as my new non-hostile link to how to ask questions.

------
aisofteng
I'd add another point to the list: when considering asking a question, first
ask yourself why the situation is such that you have a question.

That's vague, so let me give an example. Let's say you want to ask, say, why
data being sent over a network is chunked at a certain size. Before asking
that question, first ask, "why _would_ it be chunked?" You then might start
down the road of considering that maybe there a maximum size of data that can
be sent over the wire, and dig in from there and answer your own question.

Most of the time, things are the way they are because someone made them that
way - you're not discovering new land that nobody has seen before - and that
someone probably had a reason. If you try to think about what that reason
might be - if you ask "why would this be made to be this way?" \- you will
often find a way to the answer to your original question on your own without
having to ask anyone else.

Often, when learning a new library or abstraction, I ask myself, "how would I
have designed this?" Most of the time, either the way I would have designed it
is the way it is designed and it's then easy to understand, or it isn't and
the difference between how I would have designed it and how it was designed
points directly at something I hadn't considered or been aware of, giving me a
place to start understanding.

Critical thinking and careful investigation are incredibly valuable skills
that can push you ahead by leaps and bounds without needing anyone else to
help you. Those skills do take time to develop, though.

~~~
matwood
> Most of the time, things are the way they are because someone made them that
> way - you're not discovering new land that nobody has seen before - and that
> someone probably had a reason.

This is so important when reading others code or re-designing a system. It is
easy to be mentally lazy and just think that the prior system was designed
poorly when in fact it is covering many cases you simply have not come across
yet.

------
agentgt
Since this is New Years and I have... had a few... but not too many since I
have new son (3 weeks old who is sleeping hence why I'm writing this nonsense
instead of wasting time at a party) I want to come to a more broader
conclusion.

To ask a good question you have to know your audience! This includes asking a
teacher, coworker, boss, a spouse and even a _computer_ or cloud of computers
such as _Google_. You wouldn't want to ask or phrase the same questions that
you ask Google that you ask your teacher (believe me I have googled things
that are proper english and seem benign yet return horrible and embarrassing
results... on the other hand I have googled pretty embarrassing things that I
would never ask a human... usually medical).

Now the above probably seems pretty obvious to HNers but believe me it is
surprising how globally it is not.

Also as the article does mention you do need to know who to talk to first but
you also need to figure out who to ask followup questions.

I went to GaTech late 90s to early 2000s and there was a teacher there named
Jim Greenlee (who for all extensive purposes was a bastard albeit effective
bastard). Jim Greenlee was very much of the opinion that "human intervention
should be almost always the last resort" and that it is better to learn and
fail by doing.

Now I don't entirely agree with Jim but I have to say given the way things are
improving with computers you really should learn how to ask them questions and
probably first since they are increasingly becoming more effective at
answering them.

We live in a time where you need to be effective with interfacing with both
computers and humans.... Know your audience... and probably ask the computer
first since they don't seem to have feelings... yet.

------
wyldfire
> it spreads the load around

My biggest weakness/opportunity for growth is my unwillingness to ask for
help/ask questions. This strategy is key to me trying to save face and it's a
good way to learn more about my team's expertise.

> Why does rkt store container images differently from Docker? ... The answer
> I got was super super helpful

IMO you'd have gotten a satisfactory answer just by virtue of the fact that
you're posing a question about a difference from a competitive software
product. And in this case it's the market leader by far. Whenever someone
poses a difference in behavior or performance/specifications between two
similar/compatible software packages it very often inspires a lot of interest.

Aside: I think that Julia's blog posts or at least this one in particular is a
great highlight of female participation in software development. Not that men
don't post stuff like this on occasion. But it seems like the focus is often
more content regarding technical matters than social ones.

~~~
fallous
Know what you know, know what you don't know, and strive to move the latter
into the former by asking questions. Someone unwilling to ask a question when
they don't know something is a quick way to get me to fire you when that
vanity runs into reality.

Stop trying to be perceived as important and focus on actually doing important
things... the rest will sort itself out.

------
mercur1o
> I see a lot of senior engineers who frequently ask for clarifications – I
> think when you’re more confident in your skills, this gets easier.

> The more I do this, the more comfortable I feel asking someone to clarify.
> in fact, if someone doesn’t ask me for clarifications when I’m explaining
> something, I worry that they’re not really listening!

I think this is really powerful. I believe high skilled professionals tend to
have a clear idea of they know and what they don't know.

------
jwatte
The best place to ask questions for me is the internet.

It is regularly so hostile and rules lawyerly that I have to collect
everything I know about the problem into the post, and pre-empt every
objection with an existing fact.

And, once I do that, I'm almost always close enough to the solution that I
don't need to press "post." Just typing what I know into the Stack Overflow
window, and imagining all the objections to the question, structures my
question to the point of finding the answer!

~~~
keithpeter
So Stack Overflow is your version of the rubber duck?

[http://www.rubberduckdebugging.com/](http://www.rubberduckdebugging.com/)

------
505
The title made me think of Eric S Raymond. Don't miss the mention in the
article.

~~~
keithpeter
I think that I agree with the OAs opinion of esr's _How To Ask Questions The
Smart Way_. Quite a lot of rhetorical language.

I had the temerity to try writing a more neutral and very brief summary of the
ESR page some time ago.

[http://forums.debian.net/viewtopic.php?f=12&t=116898](http://forums.debian.net/viewtopic.php?f=12&t=116898)

[New Year is well past in my timezone, and I'm cooking the dinner right now]

------
known
Ask credible questions

------
happynewyear
"If you haven't already, would you mind reading about HN's approach to
comments and site guidelines?"

This question does:

    
    
       - Identify terms you don’t understand 
       - Ask questions where the answer is a fact
    

does not:

    
    
       - Do some research  // profile flag user accessed faq
       - Decide who to ask // ^
    

Happy New Year, HN!

~~~
dang
It's not a question so much as a request.

------
NicoJuicy
Grmbl, questions.

When your in IT, everyone has questions. They think it's all the same. I don't
have any time anymore to fix a or B's computer. Then I have to worry if they
are offended.

At my job, there's a junior who constantly annoys me. He starts telling his
problem with absolutely useless info and then says what he thinks the solution
would be ( he's always way off). I go to him, ask it to show it to me with
fiddler or Google console tools and almost always you can see the problem
there. It's absolutely B's.

Or he asks a stupid question where the only possible answer is yes, I think
he's doing it to show off as smart ( ps. He's obviously not and after 2 years,
he still doesn't do much)

God, I hate it

