RubyConf 2015 - Nobody Expects an Inquisition!... by Amanda Quaranto

We are constantly asking questions everyday:
How's it going?
Have you used this gem before?
Do you know where lunch is?
Well, what if asking these questions
makes us feel like an imposter,
unworthy of the job they're paying us for
and unworthy of our friends?
And what if that feeling of being unworthy
keeps us from making new friends,
from questioning our coworkers,
from learning and improving ourselves?
Well, this was me until about a year ago.
Once I realized that I was avoiding
asking questions out of fear
that someone would find out
that I didn't belong,
I made a conscious effort
to change that.
And so I'm here today to give you
A Programmer's Guide to Asking Questions.
My name is Amanda Quaranto,
and my background is in
manufacturing and process engineering.
I've worked in both aerospace
and electronics manufacturing.
I taught myself to program,
brought up on tutorials and books like
Chris Pine's Learn to Program
and Code School.
And as of March of this year
I am the Customer Support and Happiness
team lead at Travis CI.
Travis CI, for those of you who don't know,
is a continuous integration platform.
You provide your code and your test via GitHub
and we provide the virtual machine
and we can also deploy your code for you.
As always, it's free for open-source projects.
And I do have tons of stickers
so please come and get some stickers.
So I wouldn't be here today if it weren't for Travis,
but I also wouldn't be here if it weren't
for two exceptionally patient little boys
who...
sacrificed a lot of mommy time
for me to be able to come here and talk to you.
They love fist bumps and stickers
so if you see them,
please say hi to them,
and of course, they are
the cutest builders in town.
So before we dive in,
Coraline and Peter, if you can
help me out.
We're going to do a quick writing activity.
I have some exceptionally large index cards
and some pens,
it's not necessary that you have them,
but we're gonna start thinking critically
about the questions that we're asking
and not asking everyday.
So we're gonna divide this into two parts.
We're gonna have side A and side B.
Starting with side A,
I'll give you a few minutes
to get your note cards.
Poor planning for a process engineer, let me tell you.
(chuckles)
Alright, all the questions will be up on the slide
so you can can catch up as you get them.
So like I said, side A is going to be
about the questions that we're asking everyday.
So the first thing I'm gonna have you write down
is: what was the last question that you asked someone?
It's very possible that it happened
right here in this very room.
You turned to the person next to you and said,
"How's it going, what are you working on?"
Anything like that.
It could've been
something more complex
like, "How do I implement this gem?"
or, "Can you teach me how to do that?"
But whatever it was,
go ahead and write it down.
The next thing I'm gonna have you write down,
and it's gonna sound
kind of silly at first:
did you care what the answer to your question was?
And I know what you're thinking,
"Of course I cared.
"I opened my mouth
"and the words came out of my mouth
"and I directed them at a person,
of course I wanted a response."
But did you really?
In the case of asking, "How are you?" or "Sup?",
we oftentimes throw that out
as an icebreaker,
and so you don't really necessarily care
the answer to that question.
So this a simple yes or no,
did you care?
The next thing is fairly easy as well:
did you learn anything?
In the case of "How are you?",
you probably learned,
"The person sitting next to me is fine.
"They had a terrible flight in,
"they had the Quaranto baby sitting next to them",
anything like that.
What did you learn?
The next thing,
and we'll talk a little bit more about it,
is: was it a leading question?
Did it start a conversation?
Did it start an argument?
A leading question is gonna be anything
that is more than just a yes or a no question,
like this one,
this is a yes or no.
And the last thing we're gonna have you write down
for side A is: what was the outcome?
This is a little bit different
than if you've learned anything.
In the case, again, of "How are you?",
maybe you're making a mental note
to check back in with the person sitting next to you.
Maybe they said, "Fine",
and you don't really believe them, and so
you're gonna check back in with them
in a few days
to see if they are actually fine.
Or maybe you have to go Google something later,
but whatever it is, let's write down the outcome.
So let's flip over to side B.
Side B is going to be about the questions
that we're not asking.
So the first thing to write down
is: what was the last question that you had in your head
and you didn't ask?
This one is going to be much more difficult.
We think of questions all the time
that we dismiss immediately.
It's very possible that the last question
that you had that you didn't ask
happened today, maybe in a talk
that you were in previously,
you didn't have time,
or for some other reason.
So that's the next question:
why didn't you ask it?
Did you not have time?
Did you not want the person you were asking
to know you didn't know the answer?
Number three is:
what were the consequences of that?
Maybe you have to Google something later,
but maybe you didn't learn the person's name
and you didn't make a friend today.
Whatever the consequences were,
just go ahead and write that down.
Number four is:
who is the subject-matter expert
for the question that you have?
Fairly easy if I'm asking "How are you?"
The subject-matter expert is the person I was talking to,
or didn't talk to.
In the case of sitting in a talk earlier today,
it was probably the person speaking.
And the last thing, yes or no:
do you intend on asking it?
Alright, just take a second,
make sure your answers are all there.
Alright.
So let's get into the guide.
I've broken this up into
five easily actionable points,
so if you're making some doodle notes
you can make room for five things.
The first point is:
don't be content with not knowing.
People always told me that I was a great listener,
and I always took that as a compliment,
but there's more to just listening to people
than sitting there and staring at them
and hearing the words that they're saying.
Plenty can be deduced from conversation,
whether it's spoken or unspoken,
and usually, when you listen to people
talk long enough, you can figure out
the answer to most questions:
"What does that acronym mean?
"What is that person's name,
"I don't really remember?"
But if you listen long enough,
you can usually figure it out.
And I would avoid asking questions
because I didn't want people to know
that I didn't know,
and I didn't want to be wrong.
But sometimes you are wrong,
and that's okay.
This was a big one for me.
It's really, really okay to not know.
The next slide is a really great quote
from everyone's favorite astrophysicist:
"I love being wrong
because it means in that instant,
I learned something new that day",
and if Neil Degrasse Tyson can be wrong,
I suppose I can be too.
The second point in our guide
is: ask one leading question per conversation.
And we talked a little bit about leading questions,
and it's gonna be any question
that furthers the conversation
and engages the listener.
A leading questions might be a follow-up
to, for the devs in the room,
we can call a bullying question,
a yes or a no question.
So the point of asking
leading questions is to further the conversation
and to be engaging,
because by being engaging,
we can ask more and more questions
and get at the answer that
we're actually looking for.
We want to keep them engaged, as well,
because we learn more faster,
when we're asking questions.
The process of actually thinking of a question
is going to make the answer
stick in our brain a little bit better.
So number three in our guide
is: find a subject-matter expert,
and there I go using acronyms,
but subject-matter expert.
You are not a subject-matter expert
in everything,
even though some people pretend to be,
and that's okay;
this is another thing that I've had to get over.
But you can become a subject-matter expert
in anything that you want
just by asking questions.
So, in big bold letters on side B,
I want you to write down
what you are the subject-matter expert of.
It's very possible that the thing
that you're the subject-matter expert of
is Ruby,.
Maybe some other language,
maybe some other software,
some other hardware,
it could be something that's completely
unrelated to tech.
For me it's crafting.
I've been a knitter and crotcheter
for well over 12 years,
and I can confidently say that
I am a subject-matter expert
when it comes to crafting.
So you can find me on Ravelry
if you want to learn more;
if you want to learn about yarn crafts,
or how I make crazy quilts,
or how I make these awesome vinyl decals,
I'm the person to talk to
and I would love to help you and answer your questions.
Number four in our guide
is: care about the answer.
So like I mentioned before,
it might seem silly, but it's not.
We should be asking the questions
that we want or need the answer to.
Questions like: "How are you?",
"Sup?", "How's it going?",
"How'd you sleep last night?",
these are questions that we ask
all of the time without expecting an answer,
or thinking that a person
will actually respond to us.
And for some of us,
mostly consultants, our time
is measured in actual dollars,
and the point that I'm trying to make with this
is give people your time,
that we should give it likes it's free,
like it doesn't,
like I'm not on the clock,
and like it isn't a chore.
And we've heard of rhetorical questions,
questions that we're asking
without expecting an answer,
that have an obvious answer,
like, "Do pigs fly?",
or, "Who cares?"
But what about sarcastic questions,
questions that we ask to prove a point,
or to make someone look bad?
I have a fairly well-known example
on the next slide,
and I left the person's name,
or the poster's name, off of it because
we shouldn't be grabbing our pitchforks,
we should be learning something from this.
So this was written on an issue
for the Basecamp Powell Project,
it's open source,
this is just an issue:
"Yosemite is in GM status now so,
"when can I just do a simple
"merging of a pull request?
"Sheesh."
This is the infamous "sheesh" conversation,
and this was Sam Stephenson's
of Basecamp's response,
it's hard to read, it start with:
"Here's a rough list of (mumbles) to this release",
and he goes on and on,
and at the end: "Sheesh, indeed."
So the next part is three-fold:
be concise,
use as few words as possible
when you're asking your questions;
be precise,
be unambiguous,
leave nothing open for interpretation;
and be deliberate,
be planned, calculated, and researched
when you're asking your questions.
And this is especially important
in technical and professional situations.
We've heard the phrase,
"There's no such thing as a stupid question",
meaning if you can think of a question,
it's probably worth asking.
But there is such thing as a bad question,
question that's poorly worded,
poorly formed.
I think a really great example
of a poorly-worded question
is from our favorite manager from Office Space,
Bill Lumbergh.
He loves asking convoluted and indirect questions:
"So...
"you think you could be here tomorrow
cuz
"we kinda need somebody,
that would be great."
Well, did he actually ask a question here?
I mean, there's no question mark so,
kind of.
He was muddling his words
out of the necessity of,
he didn't want to be direct
and he wanted to avoid confrontation,
but there is a question here.
Another thing to remember is
to do your research.
And this is kind of obvious, I mean,
everyone I talked to about this talk was,
"Make sure you people something in
"about doing research",
but we all know to go to Google,
but we should also expand our research
to our peers, our other coworkers.
If any of you were in Gary Bernhardt's talk yesterday,
he talked about known unknowns
and unknown unknowns.
While doing your research,
you should try to make
as many of those unknowns known,
and know what you don't know.
So let's review (audio cuts off) very quickly:
don't be content with not knowing,
ask one leading question per conversation,
find the subject-matter expert,
care about the answer,
be concise,
be precise,
and be deliberate.
And I know what you're thinking,
"Yeah, okay Amanda.
"I hear you but
"why would I want to do this?"
First off, great job for asking questions,
you've all been paying attention,
but...
you can construct the most
eloquent question on the planet,
you can figure out who to talk to,
but why would you want to do this,
especially as someone
who feels like an imposter?
First off, I mentioned before,
you can learn more faster
by asking questions,
and we're far more likely to remember things,
like I mentioned, if we
form a question about it.
Similar to when you meet someone
for the first time,
you repeat their name and it kind of
goes into a different part of your memory bank.
So this is both true personally and professionally,
and one of my favorite questions
to ask people
is "What are you working on these days?"
And this is an awesome leading question,
because not only does it let someone
open up to you and it kind of
opens a conversation,
but it also gives you something to talk about
the next time you see this person.
You don't have to break the ice again,
you don't have to search
for something to come up with.
This talk has been
incredibly lacking in buzz words,
so the next benefit is face time.
Not this kind of face time,
but I suppose you could use
this kind of face time to get face time.
I'm talking about this kind of face time.
Oops.
I work remotely,
and sometimes that means the only interaction
that I get with my coworkers
is asking questions.
Whether it's the latest build release info,
or something in their personal lives...
There, it's gonna build again.
There we go.
Alright. Yeah.
Another benefit is
we can expand our knowledge
outside of tech.
I'm sure most of you don't have
only friends that are Ruby programmers
or only people that are programmers, in general.
You can learn anything.
If you wanna come talk to me about crafting stuff,
I will teach you,
and it's possible to learn anything
just by asking questions.
This next one has been
one of the hardest things for me by far,
and it's asking questions
when we're in a meeting
as coworkers,
to think critically about business
and technical decisions.
So we'll be sitting,
or in front of a computer or at a table,
wherever we are,
and somebody would be talking
about the latest build release,
and I would be sitting
at my desk, quietly thinking:
"They probably made that decision for a reason."
Whatever that reason was,
meh, it's probably good enough.
That's not okay.
It's really, really not okay.
Asking why encourages everyone on the team
to think critically about their decisions,
and it gives you a little more insight
as to why people are making these decisions,
right or wrong,
but we need to ask questions in these situations.
And that's why we have the processes
of five whys.
If you haven't heard of it,
you can determine the root cause
of any problem by answering the question
"Why?" five times.
This actually brings back memories
of my process engineering days
because this originated
as part of the Toyota production system.
The final benefit that I'm gonna talk about
is actually more of a perk
of asking questions,
but it definitely takes a lot of practice.
Negotiation,
not just in your professional life
but maybe, going out to buy a car,
you're gonna have to ask some questions.
I had originally titled this talk
Programmers Don't Ask
after a book that I read several years ago
called Women Don't Ask.
The premise of this book,
which was published in 2003,
is that women,
and underrepresented minorities,
don't feel empowered to ask
or negotiate a better salary,
or better benefits,
and they can actually miss out on
over a half a million dollars of compensation
over their career.
And since reading this book,
this is actually one of the questions
that I don't have problems asking,
I always ask.
Whether it's a salary or benefits increase,
it's worth asking the question.
So we've talked about
asking questions,
we've talked about the benefits of doing so,
let's talk about answering questions,
because I'm sure you all wrote down
in big bold letters that,
what you're the subject-matter expert of,
you're gonna have to answer some questions.
So the first thing is: remember,
you weren't always a subject-matter expert.
You had to ask questions
to get where you are.
So you should be answering questions
to the questioner's skill level.
So if you're talking to someone
who's a little bit more junior,
using acronyms probably isn't the best idea,
because while you're talking,
they're thinking back in their head,
"Oh my gosh, I don't know what that acronym means,
"I'm gonna have to look that up later,
I should write that down",
and they're thinking and thinking and thinking
instead of paying attention to you
answering their question.
When answering a question,
we should always assume the best.
Most people don't have ulterior motives
when they're asking you questions.
They aren't trying to make you look bad,
in the case of asking
questions in a business meeting,
and they're not trying to take your job,
trying to extract that last bit of knowledge from you
so they can take over for you.
Something that people answering questions
often think is
people didn't do their research.
Well, point them in the right direction.
Give them a place to start.
If you think they didn't Google it first,
maybe point them at stack overflow
or somewhere where they can find
the best information.
And, just like when asking questions,
when answering them you need to be precise,
be pre-cise,
and be deliberate.
So another thing that people asked me about
when I was coming up with
the concept for this talk,
is dealing with people who are bad
at answering questions.
So I see people falling into two categories
that people that are bad at answering questions.
The first one is gonna be
coworkers who hate answering questions,
who don't have the time to answer questions.
But these people are often
the single point of information,
these are the people that you have to talk to
to get that information.
So you go up to them, you say,
"Hey, can I ask you a question?",
and they're grumpy cat,
"No, get away from me",
alright.
So the next archetype is
equally frustrating to work with
but maybe a little bit easier
to deal with.
You may encounter coworkers
who just don't know how to answer questions.
Now, the first thing to do would be
send them a link to this presentation,
maybe I can help them out a little bit,
but you can also sit down with them,
build a working relationship with them,
these aren't bad people.
You can explain how they can best help you,
and, in the immortal words of Jerry McGuire,
"Help me help you."
Alright.
So I asked the twitterverse
how to handle coworkers, and
@joshvc had this to say:
"I can't visualize solutions
"well enough to help out."
So maybe the subject-mater expert
that you're talking to
that maybe seems like they're bad at answering questions,
maybe they have a little bit of
imposter syndrome themselves,
and they don't think they're worthy of helping you,
and maybe they need help to do that.
And for these people,
you should assume the best.
The people aren't out to get you.
They aren't sitting in the corner,
laughing maniacally,
hoping that you'll fail,
and there's your Spanish Inquisition.
(chuckles)
And if you liked that bit about buzz words,
face time, you're going to love this.
If you coworker is that grumpy cat,
or they're unresponsive
when you express your need
for more clarification,
you might have to start looking somewhere else.
In your research to be
concise, precise, and deliberate,
you may have found a helpful person
outside of your coworkers,
outside of your normal group of friends.
Find them.
Include them.
Ask them your question.
That was the most businessy thing
I've ever put in a PowerPoint.
(chuckles)
And finally, one of my coworkers
had dealt with some grumpy cats
in her previous job,
and she decided to collect them
and put them in a IRC channel
so they could all help each other.
So what's next?
Well, imposter syndrome is still something
I deal with everyday.
And you can ask Nick,
I had imposter syndrome
about my imposter syndrome talk.
I'm surprised there's people in here.
(chuckles)
The big thing that I'm working on next
is showing people things
that aren't perfect.
I'm pretty sure I could sit and add
100 more slides.
The backgrounds on these slides
are my first attempt at drawing things,
and so you're seeing
my imperfect drawings.
This is really important
because some things
are less than perfect,
and that's okay.
Thank you.
(audience applause)
How do you tell people
that they are bad at asking questions?
That's really good.
I would start by
talking them through
the things that I talked about,
sitting them down,
just like if you were to sit down
the person who is
bad at answering questions.
So he asked how to be concise
and also prove that you've done your research.
It's difficult.
So for me, because I work remotely,
I can kind of
throw a blurb
at slack and kind of
show people what I've looked at.
I think that can come out of conversation.
Start with your question,
your concise question,
and then follow up with
here are all the places that I've looked.
So he asked about getting quality face time
when we're working remotely.
This is actually,
I just got back from our Travis team offsite
and we spent a lot of time talking about
interacting with our coworkers,
especially when there's a six,
or, sometimes, nine-hour time difference.
It comes through
showing people what you're working on all the time.
We have team emails that go out frequently,
people post what they're working on.
Even if isn't like a,
if it's an asynchronous interaction,
that that's still,
"Hey, I'm here, I'm working,
"here's what I'm working on."
If you wanna talk more about that,
I would be happy to.
We did talk quite a bit
about working remotely.
Well thank you all very, very much.