Remote Work
Nobody Expects an Inquisition! - A Programmer's Guide to Asking Questions

Summarized using AI

Nobody Expects an Inquisition! - A Programmer's Guide to Asking Questions

Amanda Quaranto • November 15, 2015 • San Antonio, TX

In the talk "Nobody Expects an Inquisition! - A Programmer's Guide to Asking Questions," Amanda Quaranto emphasizes the importance of asking questions in programming and professional environments. She reflects on her past experiences of avoiding questions due to fears of being perceived as an imposter and how this hinders both personal and professional growth. Quaranto provides a guide to transform the act of questioning into a valuable tool for learning and connecting with others.

Key points discussed in the talk include:

- The Importance of Questioning: Quaranto encourages the audience to embrace inquiry instead of relying solely on intuition. She shares how many interactions, even casual ones, often lack genuine curiosity.

- Self-Reflection on Questions: The talk involves an interactive element where attendees write down questions they ask and those they don't, prompting them to consider their motivations behind these questions and the outcomes.

- Five Actionable Points: Quaranto outlines five practical strategies:

- Don't be content with not knowing: Embracing ignorance and view it as a learning opportunity.

- Ask one leading question per conversation: Engage others with questions that promote further discussion.

- Find a subject matter expert: Identify individuals with deeper knowledge to enhance learning experiences.

- Care about the answer: Approach questions with genuine interest to foster meaningful exchanges.

- Be concise, precise, and deliberate: Craft questions thoughtfully to ensure clarity and effectiveness.

- Examples and Anecdotes: Quaranto shares anecdotes from her own experiences and quotes from notable figures like Neil deGrasse Tyson, illustrating that being wrong can be a path to new learning.

- Networking and Learning: The discussion highlights how asking questions can lead to better networking, deeper knowledge, and can aid in professional growth by challenging the status quo during meetings or discussions.

- Negotiation Skills: Quaranto also touches upon the importance of asking questions in the context of negotiations, particularly regarding salary and benefits, highlighting how a lack of inquiry could result in significant long-term financial loss, particularly for underrepresented groups.

- Wrapping up: Quaranto concludes by encouraging attendees to not only ask questions but also to be better at answering them, emphasizing understanding and patience in communication. Overall, this insightful session aims to empower programmers to utilize questions as a transformative tool for personal and professional growth.

Nobody Expects an Inquisition! - A Programmer's Guide to Asking Questions
Amanda Quaranto • November 15, 2015 • San Antonio, TX

Nobody Expects an Inquisition! - A Programmer’s Guide to Asking Questions by Amanda Quaranto

What was the last question you asked someone? Did you actually care what the answer was? Did it improve the conversation? Did it start an interesting discussion? Did it start an argument?

Like many programmers, I’ve relied on deductive reasoning to avoid asking questions - fearing that someone would find out I didn't belong. At the start of this year, I made the decision to change all that. This talk will evaluate tools which improved my professional and personal life.

Let’s learn how to rely less on being intuitive and more on being inquisitive.

RubyConf 2015

00:00:16.990 Alright, we're going to get started here.
00:00:19.760 We are constantly asking questions every day. How's it going? Have you used this gem before? Do you know where lunch is?
00:00:27.890 But what if asking these questions makes us feel like an imposter, unworthy of the job they're paying us for? And what if that feeling of being unworthy keeps us from making new friends, from questioning our co-workers, from learning and improving ourselves? Well, this was me until about a year ago.
00:00:41.510 Once I realized that I was avoiding asking questions out of fear that someone would find out I didn't belong, I made a conscious effort to change that. 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.
00:01:05.689 I taught myself to program, brought up on tutorials and ebooks like Chris Pine's 'Learn to Program' and 'Code School'. As of March of this year, I am the Customer Support and Happiness Team Lead at Travis CI. For those of you who don't know, Travis CI is a continuous integration platform. You provide your code and your tests via GitHub, and we provide the virtual machine. We can also deploy your code for you, and as always, it's free for open source projects.
00:01:33.799 I do have tons of stickers, so please come and get some. 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.
00:01:48.259 They love fist bumps and stickers, so if you see them, please say hi to them. And of course, they have 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 going to start thinking critically about the questions that we're asking and not asking every day.
00:02:35.330 We're going to divide this into two parts: Side A and Side B. Starting with Side A, I'll give you a few minutes to get your note cards.
00:02:44.220 All the questions will be up on the slide so you can catch up as you get them. Like I said, Side A is going to be about the questions that we're asking every day. The first thing I'm going to 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.
00:03:07.020 You turned to the person next to you and said, 'How's it going? What are you working on?' Anything like that. It could have 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.
00:04:07.020 The next thing I'm going to have you write down, and it's going to sound kind of silly at first: Did you care what the answer to your question was? I know what you're thinking: 'Of course I cared! I opened my mouth, the words came out, 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 we don't really necessarily care about the answer to that question. So this is a simple yes or no: Did you care?
00:05:12.610 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 you is fine. They had a terrible flight in, they had the Couranto baby sitting next to them, anything like that. But what did you learn?
00:05:47.780 The next thing, and we'll talk a little more about it, is was it a leading question? Did it start a conversation? Did it start an argument? A leading question is going to be anything that is more than just a yes or no question, like this one is. The last thing we're going to have you write down for Side A is: What was the outcome? This is a little bit different than if you've learned anything.
00:06:20.030 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', but you don't really believe them, and so you're going to 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, or whatever it is, let's write down the outcome.
00:06:41.090 So let's flip over to Side B. Side B is going to be about the questions that we are not asking. So the first thing to write down is: What was the last question that you had in your head and didn't ask? This one is going to be much more difficult. We think of questions all the time that we kind of Smith immediately.
00:06:57.400 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? Did you not know the answer?
00:07:49.250 Number three is: What were the consequences of that? Maybe you had 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, go ahead and write that down. Number four is: Who is the subject matter expert for the question that you have? This is fairly easy.
00:08:22.380 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. The last thing: Yes or no, do you intend on asking it?
00:08:33.720 Alright, just take a second to make sure your answers are all there.
00:08:38.520 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 they're saying.
00:09:16.399 Plenty can be deduced from conversation, whether 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.
00:09:37.730 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 is a big one for me: it's really okay to not know. The next slide has 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.
00:10:04.230 The second point in our guide is: Ask one leading question per conversation. We talked a little bit about leading questions, and it's any question that furthers the conversation and engages the listener. A leading question might be a follow-up to, for the devs in the room, we can call a boolean question a yes or no question.
00:10:21.560 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 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.
00:10:40.540 Number three in our guide is: Find a subject matter expert. 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.
00:11:02.549 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 are the subject matter expert of is Ruby, maybe some other language, some other software, or hardware. It could be something that's completely unrelated to tech. For me, it's crafting. I've been a knitter and crocheter for well over 12 years, and I can confidently say that I am a subject matter expert when it comes to crafting.
00:11:25.219 So you can find me at Unravel Ray 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.
00:12:29.479 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 did you sleep last night?'. These are questions that we ask all the time without expecting an answer or thinking that they will actually respond to us.
00:13:04.220 And for some of us, mostly consultants, our time is measured in actual dollars. The point that I'm trying to make with this is to give people your time. We should give it like it's free, like we’re not on the clock and like it isn't a chore.
00:13:28.139 We've heard about rhetorical questions—questions that we're asking without expecting an answer. They 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.
00:13:52.420 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. This was written on an issue for the Basecamp Powell project. It's open source; this was just an issue you send these in GM status now.
00:14:02.940 So when can I just do a simple merging of a pull request? Sheesh! This is the infamous 'sheesh' conversation, and this was Sam Stevenson's response. It’s hard to read it; it starts with 'Here is a rough list of what went into this release,' and he goes on and on. At the end: 'Sheesh, indeed!'
00:14:48.460 The next part is threefold: 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. This is especially important in technical and professional situations.
00:15:04.640 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 a thing as a bad question. A question that's poorly worded.
00:15:38.260 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? 'Cause we kind of 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 necessity.
00:16:02.600 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. This is kind of obvious; I mean, everyone I talked to about this talk said to make sure you put something in about doing research. But we all know to go to Google. We should also expand our research to our peers, our other co-workers.
00:16:35.800 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 those vertically: Don't be content with not knowing, ask one leading question for a conversation, find the subject matter expert, care about the answer, be concise, be precise, and be deliberate.
00:17:19.160 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! 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?
00:18:02.910 First off, I’ve 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. This is both true personally and professionally.
00:19:06.680 And one of my favorite questions to ask people is: 'What are you working on these days?' This is an awesome leading question because not only does it let someone open up to you and 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.
00:19:41.340 This talk has been incredibly lacking in buzzwords, so the next benefit is FaceTime. Not this kind of FaceTime, but I suppose you could use this kind of FaceTime to get FaceTime. I'm talking about this kind of FaceTime. Oops! I work remotely and sometimes that means the only interaction that I get with my co-workers is asking questions. Whether it's the latest build release info or something in their personal lives.
00:20:19.560 There's going to build again. There we go! So 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 want to come talk to me about crafting stuff, I will teach you.
00:20:52.410 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 co-workers to think critically about business and technical decisions.
00:21:11.820 So we'll be sitting in front of a computer at a table, wherever we are, and somebody would be talking about the latest build release, and I be sitting at my desk quietly thinking they probably made that decision for a reason, and whatever that reason was, it's probably good enough. That's not okay. It's really, really not okay.
00:21:55.320 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 process of the 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.
00:22:38.220 And 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 going to 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 going to have to ask some questions.
00:24:07.130 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 half a million dollars of compensation over their career.
00:25:07.410 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, and let's talk about answering questions because I'm sure you all wrote down that in big bold letters what you're the subject matter expert of, and you're going to have to answer some questions.
00:25:56.650 So the first thing is to 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 at the questioner's skill level. If you're talking to someone who's a little bit more junior, using acronyms probably isn't the best idea.
00:26:46.490 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 going to have to look that up later.' They should write that down, and they're thinking and thinking and thinking instead of paying attention to you answering their question.
00:27:27.640 When answering the questions, we should always assume the best. Most people don't have ulterior motives when they're asking 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 or extract that last bit of knowledge from you.
00:28:05.760 Something that people answering questions often think is people didn't do their research. While pointing them in the right direction, give them a place to start. If you think they didn't Google at first, maybe point them to Stack Overflow or somewhere where they can find the best information. Just like when asking questions, when answering them, you need to be precise, be precise, and be deliberate.
00:28:45.520 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. I see two categories: people that are bad at answering questions, and the first one is going to be co-workers who hate answering questions and don't have the time to answer questions.
00:29:37.480 These people are often the single point of information. These are the people that you have to talk to get that information. So you go up to them and say, 'Hey, can I ask you a question?' and they're like, 'No, get away from me!'
00:29:58.760 Alright, so the next archetype is equally frustrating to deal with, but maybe a little bit easier to manage. You may encounter co-workers who just don't know how to answer questions. The first thing to do would be to send them a link to this presentation; maybe I can help them out a little bit.
00:30:38.320 But you can also sit down with them and build a working relationship with them. These aren't bad people, and you can explain how they can best help you. And in the immortal words of Jerry Maguire: 'Help me help you!'
00:31:20.970 Alright, so I asked the Twitterverse how to handle coworkers, and @joshbc had this to say: 'I can't visualize solutions well enough to help out.' So maybe the subject matter expert that you're talking to, that maybe seems like they're bad at answering questions, they might have a little bit of imposter syndrome themselves.
00:31:44.050 They don't think they're worthy of helping you, and maybe they need help to do that. For these people, you should assume the best. These people aren't out to get you. They aren't sitting in the corner laughing maniacally hoping that you'll fail.
00:32:01.460 And there's your Spanish Inquisition! And if you liked that bit about buzzwords, FaceTime, you're going to love this. If your co-worker is that grumpy cat, or if they’re unresponsive to when you express your need for more clarification, you might have to start looking somewhere else.
00:32:31.720 In your research, be concise, precise, and deliberate. You may have found a helpful person outside of your co-workers, outside of your normal group of friends. Find them, include them, ask them your question.
00:33:02.740 What’s next? Well, imposter syndrome is still something I deal with every day. You can ask Nick; I had imposter syndrome about my imposter syndrome talk. I’m surprised there are people in here!
00:34:07.780 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 a hundred more slides. The backgrounds on these slides are my first attempt at drawing things, and so you’re seeing my imperfect drawings.
00:34:36.649 This is really important because some things are less than perfect, and that's okay. Thank you!
00:35:15.350 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.
00:35:33.510 So, he asked how to be concise and also prove that you’ve done your research, and it’s difficult for me because I work remotely. I can kind of throw a blurb at Slack and show people what I've looked at.
00:36:23.589 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.' Yeah, so he asked about getting quality FaceTime when we’re working remotely, and 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.
00:37:05.980 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, and people post what they’re working on, even if it's an asynchronous interaction. That's still, 'Hey, I'm here, I'm working; here's what I'm working on.' If you want to talk more about this, I would be happy to.
00:37:45.880 We did talk quite a bit about working remotely. Well, thank you all very, very much!
Explore all talks recorded at RubyConf 2015
+76