 Hi everyone, welcome to open source summit 2020 virtually this year. So today I will be sharing my thoughts and experience with you all on giving and getting technical help without being scared. I will begin this talk with a brief introduction about myself. So my name is Sonia Singla and I am on the release notes team as shadow for Kubernetes 1.20. Recently this summer I completed my CNC internship with Thanos project and I was the past outreach intern at Mozilla Firefox. So today my talk is on giving and getting technical help without being scared. Asking questions can be hard. I first discovered that asking can be really hard when I was 17 years old in the first year of my college and at the same time I was beginning with open source. So we had a class as well as a lab for straight 3 hours on the subject called oscillations and optics. During class whenever the teacher asks any question boys would blurt out without even thinking while the girls would raise their hands get shouted over then they don't say what they actually want to say. And I was actually in the third category you know just observing things around me. So you know in the same lab we were divided into groups of three and in my group I had two boys along with me. The teacher used to say club into groups of three as assigned open your lab manuals and here's all the required material for performing the practical. So yeah go for it and what I observed at a time is there was no curiosity among girls. But the boys you know used to run perform the practicals very quickly and the girls used to sit wait for them to finish so that they can write the recordings. Which came out while performing the practical and the other day I had this thought in mind in what type of culture I am living. It was emotionally weak for me and as I mentioned at the beginning of the talk I was also beginning with open source at that time. So yeah helping can be hard. Whenever I got stuck with something or asked someone or send them a DM most of the time nearly 95% I didn't hear back from the person. I developed this thing in mind that just because they are good at something doesn't mean they should be arrogant right. No they shouldn't and maybe they aren't and trust me the mentors in open source are among the kindest people in the world I ever know. Maybe the person was busy. I was not asking question in right method or there could be like billions of reason. But when I started restructuring my questions doing proper homework before asking many things were changed for me. You know it was like another side of the coin. But what I observed common in open source mentors and college teachers is that they are rushed to help girls more quickly than the help boys. They let the boys struggle a bit with the work they are doing and implicitly sending a signal that the boys are more capable and ultimately figure it out. So yeah helping is culture. And at that time I felt that the system is biased and privileged. It's totally understandable that the mentors want to help underrepresented people in tech to help them grow become better engineers have learned in making money in promotions so that you know there is a balance reduced gender gap more diversity and inclusion in the tech industry. Opportunity and visibility not advice so you know what members of underrepresented groups in tech often need is opportunity and visibility. Not the advice they have to work extremely hard and be extremely good at whatever they are doing to combat the systematic privilege and unconsciousness biasness at play in our work environment. They are consistently under promoted and under compensated for their work even though they are excellent at their work. So yeah these are the lines from Christie Tillman advice is just one thing a mentor give but there are residual benefits from visible proximity and tangential relationships to be gained. So yeah think upon it. Okay this summer when I did my community bridge in town trip with Thanos project of CNCF. But they can pull us they both were my primary mentors and I don't know if they are listening to me right now. And most of the time I spent working with them. I saw how they both let me struggle with the code I was writing how they helped me to Google myself how they helped me to grow and more importantly become self independent. So yeah helping is a culture or help culture of helping others creating the culture for our community culture of people in tech and for me it absolutely turned down the culture and I saw how big helping can be. It really make a huge difference in how the whole organization community or maybe class of bunch of student fields and it helps me in transitioning. So the culture of the organization plays a very important role and also focuses in terms of learning, helping and if you have this kind of culture in your organization or company. It means that you are doing absolutely great. You can hire amazing people more diversity among the organization. You can take Junior Fox grow them into amazing senior folks. So today we are going to talk about giving technical help and getting technical help. And I'm going to share some of the specific tools for making those two things easier because you know they can be really challenging. So without further ado let's talk about asking and first let's talk a little bit about the mindset of asking and then about specific tools that you can use to make it more useful. So as a developer it's exciting and challenging to stay up to speed with the latest trends in technology. Everyday new challenges, frameworks and devices capture our attention and spur conversations in meetups, forms and chat groups. However our developer community is made of people not the tools and it's really fascinating to explore its socio-political aspects. So software engineers they are never done learning as our field is always changing. We are always being at some things and expert at others. Along the way from beginner to expert we ask a lot of questions but it can be intimidating to ask for help and I totally agree here. So first of all the key rule is to remember that even if you are talking to a person who is super senior or a junior or a person who is starting with the programming they don't necessarily need to know everything. And the same is applicable on you. Being a senior doesn't mean that they know each and everything. It simply means you know some of the stuff, they know some of the stuff and you both know some of the common stuff. Even if your code is not running giving you errors or your application is not building or might be you are confused. It's a sign of progress. It means that you are about to learn something new and be sassy and brave enough to step in. It's scary and intimidating at the same time but anyway you have to push yourself through it. So yeah here are some of the tools that you can use for asking. So the first one is choose the right place to ask. I know it sounds kind of weird but I just want to put this up here and I believe that it's a base level importance. Because if you are working in a toxic culture no matter how good, how brave you become at asking you will definitely going to end up in a bad situation in a bad time. The people who are the founders, leaders are going to set the culture. So listen to them and even if you are interviewing with them ask them lots of questions whatever you have. So that you know that you are going to end up in good hands, good place. Also online firms, Slack channels, IRC are a much better place to ask. It just depends upon the organization to organization as every organization follow different norms, different communication channels. Once you find a place don't just barge in. Have a look around how a particular community works before you demand for help. Because you know this should be the basic technique. In some forms the same question gets asked over and over. So do your homework properly before asking. A simple Google search might give you your answer. It will also avoid antagonizing the regulars. A lot of my Google searches directly me to the sites like Quera, Stack Overflow, GitHub, Stack Exchange, which are the excellent sources for the programming help. And a few don'ts. Don't expect to be spoon feeded. Don't get annoyed if you don't get an answer in the first few hours. People ask you for more details. Someone tells you that you are doing it wrong. They will and you can almost count on it. Okay, so the second key thing is practice a 15 minute rule. 15 minutes to solve the problem any way you can. However, if you don't have an answer after 15 minutes, you must ask someone. Because if you keep escalating bugs without even trying to figure it out, you're never going to learn how to solve problems on your own for yourself. When you're going to ask for help, you are at least armed with the full context of the problem at hand. The third thing you can do is explain what you're trying to do. Your big picture will take some time to explain the things clearly, whatever you're experiencing. Because if you're secretive about what you're doing, people might assume that it's your work assignment or, you know, maybe you're working on some commercial or it could be anything. Don't say I tried to run XYZ and it didn't work. Please help. You won't get any responses or even if you do, they are likely to be sarcastic and unhelpful. If you are lucky, someone might say I can't help you unless you give me more details. There are a lot of very clever and helpful people on the internet. But if you don't give them enough information to be able to help you, they simply can't and it will frustrate them because they would like to be help you out. Okay, hence, you know, it will end up in a rude reply. Whenever you are explaining things, suggesting things, don't say I think, delete I think, say whatever you want to say without using the word I think. I might be using a lot in this talk. Yeah. So the fourth thing is so say what you have already tried. Maybe by sharing your code error messages, the exact commands that you're using, because sharing error messages are really helpful and maybe before sharing, try to Google them by yourself. Try those solutions and it's always good to ask questions. Sometimes you might not understand the error but someone else might will say I tried using this data structure instead of this one. I tried looking it up on stack overflow on GitHub. I have read the documentation, but I didn't really understand this particular section. You can give a history of whatever you have gone or, you know, already done. The fifth thing is say thanks and give feedback. Always come back and say thanks and share your feedback, whatever you have tried and what was helpful to get you out of the situation and let people know if their advice helped you. This isn't much of a payback for giving out free help, but if you can let people know their solution was helpful, this will be your reward. Also, it's an investment in goodwill. They are likely to be there for you next time. If you were one of those who say, you know, thank you for your help, it now works perfectly or maybe share the feedback with the person. So yeah, this, this is really amazing. So to sum up asking here are five tools. Choose the right place to ask. Practice a 15 minute rule. Explain what you are trying to do your big picture role. Say what you have already tried. Say thanks and feedback. So yeah, this is all about asking. Now let's talk about helping. Before I start on helping, this is really hard thing to do and we are never taught how to give critical feedback effectively. We are never taught how to be good leaders, how to be mentors. We are not taught, you know, how to be experts. We are just figuring out the things as we go along. Another thing that's challenging is remembering all the things. Being an expert can actually make it very difficult to remember what it's likely to not understand. What a variable is a variable is a very challenging concept to people who have never programmed before. And you can focus on that very easily when you spend all the day in an IDE or at the command line or whatever knowing something super well. It makes it really hard to remember what it was like before and that it can make it very hard to hear them very frustrating. You have all probably helped people who are new to technology. So now I'm going to share some of the specific tools that you can use to help someone. The first one is encourage asking questions. So whenever people ask questions, be welcoming, be gentle, be compassionate and curious. Support people emotionally when people ask you questions like, hey, this is a great question. Be excited about the problem, the work. Problem related stress can make people seem rude or stupid even when they are not. And there could be other two scenarios. The first one is you're not getting enough questions at that time, reward question asking. The second thing is you are getting lots of questions. Teach them how to ship. If the people are in the first few months, deal with them. And it's not really like you want to proceed, maybe shave their behavior. For example, teach them how to debug effectively. We have to look for help whenever they are stuck. How to refactor code. Let them struggle a bit. Because that's how we learn and grow, right? The second point is create healthy environment. By a healthy environment, I mean you should treat the people asking questions like there are competitors or friends. You shouldn't underestimate them. For example, if they're asking what is X, Y, Z, you should never say you don't know even X, Y, Z. This makes the environment really ugly, toxic, as well as a lot of discouragement. Now, the third point is explain the process and reason. So after getting the question from the people, you should explain the complete process to learn. By process, I mean how the things are running behind the scenes. You should provide them enough data or maybe documentation links so that they can understand better. There might be things or concepts which you understand, but they don't. Tell them how you approach the solution for the certain complex problem. How are you making decisions? How are you choosing the particular data structure? You should also tell them the reasons why we made this thing or feature like this. In this step, you must have to make sure that you are just not spoon feeding them. But providing enough resources from which they can learn after which you gave them basic ideas. This goes into a really long way, but it will make a very big difference. The fourth point is help them to grow. Don't just grab their keyboards. Always ask first. I have seen this in many communities and this is really harmful. Grabbing someone's keyboard and solving problems for them. When the users or contributors are getting more ideas about your project, you need to make sure that the wheel is running continuously. There should be a healthy environment so that they can turn into maintainers one day. After a certain point of time and help others. Last but not the least, use inclusive language. By inclusive language, I mean don't use the words like easy, obviously just. Because if something is obvious to you, doesn't necessarily mean obvious to another person. And if it's not obvious, it clearly states you are insulting someone. So try to not use these types of words in Githapur request forums or discussions. There are many times when your tone is misinterrupted by the other person. So maybe add my emojis to that. Use some encouraging words or try to explain the things constructively as well as politely. So to sum up and courage asking questions, create healthy environment, explain the process and reason, help them to grow use inclusive language. Successful community. So building a successful and healthy community takes a long time. But after a certain point of time, the result will be so sweet. Contributors will become maintainers and this chain will keep increasing and growing over the time. But the main point here is to keep in mind that don't push your support too much. You should have a balance for the same. Because if you push them too hard too far, it can discourage them and backfire at the same time. And if you keep supporting and helping them at every point, they will not learn how to solve problems on their own. So keep a balance for that. Yeah, thank you. And if you have any questions regarding this talk, or if you need any kind of help, please feel free to ping me out. Here's my github and Twitter handle and I mentioned my website. Yeah, thank you so much everyone.