 get started here, constantly asking questions every day. How's it going? Have you used this jump 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 co-workers, 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 Caranto, 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 Pines 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. And Travis CI, for those of you who don't know, is a continuous integration platform. You provide your code and your tests via GitHub, and we provide the virtual machine, and we can also deploy your code for you. And 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. 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. So we're going to divide this into two parts. We're going to have side A and side B. Starting with side A, I'll give you a few minutes to get your no cards. Poor planning for a process engineer, let me tell you. All right, all the questions will be up on the slide so you can catch up as you get them. So like I said, side A is going to be about the questions that we're asking every day. So 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. 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. 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? 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 ice breaker. And so you don't really necessarily care the answer to that question. So this is 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 Caranto babies sitting next to them. Anything like that. But 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 going to be anything that is more than just a yes or no question. Like this one, this is a yes or no. And the last thing I'm 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. Or 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 would kind of 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. And 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, let's 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? All right, just take a second, make sure your answers are all there. 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 wanna 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. And 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. And 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. 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. And 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 crocheter 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 you. 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 did 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 like 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 POW project. It's open source, this was just an issue. You'll send me some 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 Stevenson's of Basecamp's response. It's hard to read. It starts with, here's a rough list of what into this release and he goes on and on and at the end, Sheesh indeed. So 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. 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. And I think a really great example of a poorly worded question is from our favorite manager from Office Base, Bill Lumberg. He loves asking convoluted and indirect questions. So you think you could be here tomorrow because 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 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 put 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. And if any of you were in Gary Bernhardt's talk yesterday, he talked about known unknowns and unknown unknowns. And 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 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. And this talk has been incredibly lacking in buzzwords. So the next benefit is FaceTime. And 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 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. All right, 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. And whatever that reason was, 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 process of the five why's. If you haven't heard of it, you can determine the root cause of any problem by answering the question why five times. 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 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. And I had originally titled this talk, Programmers Don't Ask. After a book that I read several years ago called Women Don't Ask. And 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 answering. I are 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 that in big bold letters 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 questions, 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. And 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 precise 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. And so I see people falling into kind of two categories that people that are bad at answering questions. And 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 and you say, hey, can I ask you a question? And they're grumpy cat, no, get away from me, all right. 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. All right, so I asked the Twitterverse how to handle coworkers and at JoshVC 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. 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. These 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. And if you liked that bit about buzzwords, FaceTime, you're going to love this. If your coworker is that grumpy cat or they're unresponsive to your, 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. 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 an IRC channel, so they could all help each other. So what's next? Well, imposter syndrome is still something I deal with every day. And you can ask Nick, I had imposter syndrome about my imposter syndrome talk. I'm surprised there's people in here. 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. And this is really important because some things are less than perfect. And that's okay, thank you. 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. Right, so he asked how to be concise and also prove that you've done your research. And 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 all the places that I've looked. Yeah, so he asked about getting quality face time 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, especially when there's a six or sometimes nine hour time difference. And 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, just even if it isn't like a, 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 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.