 Welcome, everyone. Thanks for coming to my talk. Quick note, I had planned to thread a bunch of clothing related puns throughout this talk, but darn, I don't know if I would have been able to knit together a coherent talk about mentorship. So instead, allow me to introduce myself. I work at a company called Stitch Fix. My name is Jonathan Wallace. At Stitch Fix, we help our clients become their best selves. We are a personalized styling service, and we do some cool stuff. We do some cool stuff with machine learning and data science, and we use some tools that you may be familiar with. We use Go, React, Angular, some Rails, some Ruby, actually a lot of Rails and a lot of Ruby, and we're hiring. So if you want to learn more about our company or what kind of things we do in the engineering department, you can get in touch with me or you can come see us by our booth in the exhibit hall. So today, I'm here to share my thoughts about mentorship with you, and I appreciate you coming. This isn't a real specific talk, but we'll be talking about techniques and strategies and philosophies that, when employed, will drastically accelerate your career and your skill growth. The plan for today is to discuss, first, what exactly mentorship is, and then we want to talk about why you might be interested in doing it, and then we'll go into some details the how of good approaches and actual tactics to be effective. So let's talk about the what. Mentorship can be formal. It can be something that you do on a regular cadence. It can be scheduled. You could have 30-minute meetings every week or bi-weekly, but it can also be something that is informal and intermittent. It can be something that's ad hoc where your mentee reaches out to you when they have something to talk about. Something that I think is very important for it to be effective is that it should be altruistic. Now, it's possible you're mentoring as part of your job, so you are receiving some money along with that. So technically you're getting paid, but what I think is key here is that you're sincerely invested in the results of your mentee and how they do and how they grow. So I think of that as being altruistic. So it's not about the money. You're sincerely invested despite what other motivators there are, and that's really important. If you are getting paid outside of a job, it's probably not a mentorship relationship. It's more like a coach or possibly some type of teacher. When you're mentoring, you're not focused on a particular growth and a particular skill. It's a little bit broader than, a little bit larger. You're looking at the longer term view. So that leads me to talk about the mentee and what they bring to the table, and I think it's really important to realize that they bring the fuel for the relationship and they bring the spark. But as the mentor, your job is to be the accelerant. You're accelerating their learning and their development, and we'll talk about this more later as I think this is probably one of the most important aspects of mentorship, and that's why it gets the animated gif. You're also taking the longer term view of their career growth or their skill set that they're trying to grow. Your future focus for your mentee. You have to have a vision. You don't have to have a vision, but it's nice to have a vision of where they might go in their career or how they may grow their skill set. It may not be the vision that they ultimately align with over the long haul, but you're helping them develop their vision more quickly. Let's get into the why. Why might you want to do something like this? One of the key aspects that I found a lot of value in it allowed me to practice my leadership skills in a very low stakes environment. The consequences are low. You'll get many opportunities to course correct along the way. Catastrophic failure is very unlikely, and this is a great opportunity to practice those leadership skills in the small. The stakes are low. You may lay out a plan of growth for your mentee. Let's say you're developing somebody who is new to Rails and new to programming in general. They may decide that you may sort of share out with them the specifics of how our industry is laid out in terms of career growth. You could talk about a back end developer, a front end developer, a UX, or maybe a UI designer, and this person may indicate interest in one or the other. Let's say they decide to be a back end developer. And over time, maybe a couple of weeks, they find that they're gravitating more towards the front end. That's okay. That's an opportunity for you to reflect and reset your expectations as to what they may need to focus on. You also get opportunities to practice your listening skills. People rarely say exactly what they mean. They tend to use a lot of words and go on and on and on when just a few may suffice. This is pretty normal. This is called casual conversation, and it can be challenging to understand what somebody is trying to get, what point they're trying to get to. But this is often how knowledge is constructed for us as individuals. We will practice, as a mentor, you will practice active listening skills, and that'll help you be more adept at identifying what someone's intent is. And this is incredibly valuable no matter what sphere you use it in. It's valuable whether you're speaking with executives, peers, coworkers, family, children. All these things are incredibly, when you can understand what somebody's trying to get to before they get there, it allows you to be more effective in your communication, which is key. As I mentioned before, casual conversations may be meandering as someone constructs their understanding of a new idea, whether that's a framework, an application, a programming language construct, a programming language in general. And one reason for this is that inexperienced folks are often lacked of vocabulary to know what they want. They may know what they want, excuse me, they may know what they want, but they don't know exactly how to express it. Have you ever had a problem like that where you're trying to solve a problem and you want to use a search and to help you find the solution and you can't? A few weeks ago, I was attempting to automate the installation of a Linux distribution called Debian. And I knew that this was possible and I found out how to do this for Red Hat relatively quickly, but I struggled to find the exact phrase that would give me the answers I needed for Debian. I searched for phrases like automated install or keyboardless install or keyboardless installation didn't have any luck and it took a couple of days, spread out over time before I found that the correct phrase was unattended install that led me to something called precede in Debian. It was fantastic. This is a problem that all of us have experienced in software development and in other fields, just not knowing the right words. Another challenge is that inexperienced folks may not know what they don't know. This is Donald Rumsfeld. He was the Secretary of Defense in 2002 and he has a quote that's applicable here. I'm not gonna read it directly, but he talks about the unknown unknowns and experiences what allows us to take those unknown unknowns and turn them into known unknowns. A good friend of mine, Pamela Vickers, gave an excellent talk about this in great detail called Crossing the Canyon of Cognizance. And as a mentor, you're often assisting mentees in helping them turn those unknown unknowns into known unknowns. And the way she phrased it was you're helping folks get to conscious and competence where they're actually aware of what they don't know. And that's incredibly important. I highly recommend that talk, by the way. So mentoring others also allows you to refine your conceptual knowledge and strengthen your vocabulary around a particular domain. So a mentee may ask a question where you think you know the answer and then when you go to explain it, they become more confused. And you may realize that your explanation or maybe your understanding is either not as refined as you would like or not as clear as you would like or maybe they're coming at it from a different angle and they have a different way of conceiving it. And when you bridge that gap of understanding between you two, you will find that you've augmented your own understanding. Maybe you've added a new way to conceive of that particular topic. Additionally, it's also possible that they may use different words than you expect as well. So you're also expanding your vocabulary. I like to think of this as knowledge as being this formless void, the sum of all knowledge. And what we're doing here collaboratively is turning that formless void into a labeled map. It's also possible that they may ask about something which that you don't know anything about and you'll have to go do some research and then it will inspire you to acquire some new knowledge. And then next, they can also inspire us with their efforts. So they can remind us how much work it takes to acquire that knowledge. And for me as someone who's been involved in the community for a while and been a software developer for a few years, I find that that's a good reminder to stay humble to realize how far I've come and recognize the effort that it takes to get there and appreciate that in others. So let's talk about how and start getting into the details. First, I wanna talk about how you might find a mentee. This is pretty straightforward. Whether you're into functional programming, apprenticeship, mentorship or any other topic, there's a collection of folks on the internet who probably share that same interest. So the key is to find those folks on the internet whether it's a Slack organization, a forum, IRC channels and go to those places and be helpful. In real life, you can go to meetups and hackathons and find folks who are also getting into software development. Many years ago, I attended a startup weekend and I remember meeting someone there and he goes, this is my first weekend ever trying to write software. Little did I know that three or four years later I would be working with that person and I found it incredibly inspiring that he came to a startup weekend with no experience, started teaching himself, gave talks at local meetups and I was able to help him out along the way specifically on that weekend but later on we were working together. So when you go to these places whether it's online or in real life, you wanna talk about whatever you're passionate about. Maybe you can talk about mentorship and it's value to you, you can even present and maybe a local meetup. Or whatever your passion may be if it's not mentorship or something, it's some other topic, you just wanna talk about that, share your expertise, share your challenges. That's incredibly important to share where you're struggling and you'll find folks that if you're available and helpful to others, you'll find that other folks will recommend you as a resource to potential mentees. You wanna develop your brand as a caring, helpful person whether it's about a topic which you are passionate about or not, you still wanna develop that brand and that may also help folks recommend prospective mentees to come see you. So another avenue that I'd like to touch on is children, volunteering. You can go coach at a chess club, a local chess club at a local school or a robotics club or some type of athletics. There's boys and girls clubs, there's numerous organizations out there that would be happy to have somebody come out and help out. And mentoring younger children which is something I did when I was in college. I coached soccer from kids, you three, two and three-year-olds and four-year-olds all the way up to you 19 and what you find is that the challenges of communication across all boundaries and if you can communicate with a three-year-old who's still struggling to acquire language in general, you can communicate with almost anyone. So it's also low stakes. They're such great little engines of learning that they will course correct for you faster than you can for them but it gives you a great opportunity to practice that. So one of the important things in my mind is that you wanna let the mentee drive the relationship. If you're driving the relationship that's probably not the right way to go about it. So your mentee may have objectives and goals or they may not and that is completely all right. They may have a problem to talk through when you meet up but they may not and that's okay as well. You don't have to be afraid to reach out and schedule. There's one exception where I think it's okay that it's important to reach out and schedule and that's if you feel that the relationship may be fading a little bit. When I was doing my research for this talk I came across this quote, I thought it was an apt way to put it. If you feel it's fading, it's not a bad thing to reach out and say, hey, it looks like you may not be getting value or you're too busy and that gives them a chance to say, hey, I've been too busy. I would still like to meet with you at a future date or maybe they could say, you know what? Yes, other obligations or other priorities have become more overwhelming and I need to cut this short for a while and it gives you a way to provide some closure to that experience. So when I gave my talk proposal, I put some fancy terms in there. One of those was inquiry-based learning. So the idea behind this is that the mentee is driving but you're trying to keep them on the road and make sure they don't get any accidents or travel down any dead ends. And one way to do that is to follow this philosophy. It's primarily a pedagogical method that was developed during the 60s as a response to the traditional forms of instruction where you sit down and you memorize a bunch of information. And this philosophy can be thought of as a constructivist philosophy and the idea is that for somebody to learn something, you want them to generate information and make meaning of it based on their personal experience as opposed to rote memorization. This philosophy indicates that the learner is actually participating in the process. They're not just a receptacle of information. So it's very important to remember that inquiry-based learning is experiential. They should be experiencing things along the way. And I find that experience is most often sticky and stays with somebody and has value when there's some effort that is expended to go along with it. Another thing you want to do is in inquiry-based is ask questions. You can think about this as the Socratic method. So let's say your mentee comes to you with a question about routes and rails. So my first questions would be focused on determining exactly what their concern is. Is this an aesthetic concern about using restful routing? Is this something specific that could be solved with a visit to the rails guides and the route section? You want to determine exactly what their challenge is. And the goal is thereby asking these questions as you're hoping to facilitate autonomy for your mentee. And we want to ultimately get them to a place where they can take those unknowns, unknowns and turn them into known unknowns on their own. We want them to be autodidactic, which is another way of saying that we want them to be self-teaching and need us less and less over time. So let's talk about the four attributes of inquiry-based learning. The first is as a newbie in your field or in an endeavor, your ability to distinguish signal from noise is often very challenging. It hasn't yet been developed. So because of this, it is easy to be let astray and be confused. So it's important that the information that they're learning is not deceptive. Another good friend of mine, Kylie Stradley, gave an excellent talk about this called Amelia Badelia learns to code. And she talked about beginner confusions that are very common. I remember when I first started learning Rails, this was something that I experienced. And I struggled to distinguish between the executable rakes command and the Rails executable command and what those things did. And I think now, since then, in more recent versions of Rails, we've tried to address this to some degree. But that's one of the important things is that inquiry-based, for somebody to be driving that process forward, that the information be structured and as a mentor, that's part of what we're doing. We are guiding them through that structure. And there was a great blog post in December of 2013 on the Code Fellows blog. And this is a diagram, you're not supposed to read it, so don't stress out it. But this is a diagram of everything that they indicated that you need to know to be an effective full-stack Rails developer. And I really want to reiterate, this was in 2013. And that's changed, things have changed. That's been four years since that's happened. So they talk about why learning Rails is hard and we can see why there's some value and some mentorship to help folks navigate this. So how much time should someone spend when they're learning the command line? This is the type of question that as a mentor, you will help. In my opinion, you want to make that very small. You want to give them the basics. If they're new to software development, you may show them that the terminal, just a couple of commands using CD, things of that nature. And the reason, the third point is you want to make sure that the knowledge that they have is transferable. So if they're learning how to develop software, they can use that in other languages. If they're learning how to use the command line, that skill lasts forever. So the fourth point is that you want that structured knowledge to also be easily retrievable. One of the values that I really appreciate about our community is that we do place a relatively high value on documentation. It's not 100% across the board, but we do have the fancy Rails guides, which is something that I still use today. So I wanted to get into specifics for doing inquiry-based learning with your mentee and walk through what that process might look like. We want them to devise their own questions. So again, let's say we're mentoring someone in Rails and they want to apply a discount to something that's a product. And maybe they want to change the sales price. And they come to you asking for help modeling that. I think you might want to talk about the different approaches with them. You could talk about the value in having logic in the controller. You could talk about the value and benefits of having the logic in the model. Maybe where it's being called from the controller. You could talk about the value of using callbacks or you could talk about the value using service objects. The idea is by asking them questions, you want to expose them to a bunch of ideas and then facilitate them going and doing some research on their own. And when I say doing research, it may be that they are going out and looking up blog posts or maybe they're spiking out an approach and trying it out to see what it looks like. And then after they've done that, you want to come back to you and sort of explain what's going on and share that experience with you. And you're hoping to find that they're able to explain it, their reasoning and their thought process through the research that they've done. This is a great opportunity to facilitate their growth with respect to how to find things on the internet because that may be challenging as well. And then finally, you want them to develop an opinion about it. This is incredibly important because this is where they're really constructing their knowledge and finding a way to imprint it in their brain and retain it and over a longer threshold of time. You want them to make an argument that makes sense. So this isn't prescriptive, it's just a general guideline and there can be loops in this where you cycle through the first couple of steps a couple of times, that's normal. So the next thing I want to talk about was differentiated learning. And this is a fancy term for teachers that they use to talk about the fact that children learn in different ways, which we can generalize into the fact that people learn in different ways. People have different learning styles, we all have different strengths and different weaknesses. Specifically, we all have different zones of proximal development. And this is another fancy term that was developed by a Russian named Lev Vygotsky. And it is the difference between what a learner can do and what a learner can do without help. So here's a great image that shows that visually. If you're a visual learner, I wanted to make sure to share that. On the outer ring, we have what the learner may not be able to do yet. Maybe they can't develop Facebook on their own. And then in the middle, there's a set of tasks and challenges where a mentee may tackle those and they may need some help along the way. And then in that inner circle, you have where a learner can accomplish the task on their own. And our job is to fill our mentee with tasks and challenges and make sure they're focused on the right task and the right challenges that are in that middle tier. We want to make sure these tasks are not too difficult. We want to make sure they're not too easy. We want them to be just right to facilitate their growth. Another thing to ask yourself about your mentee is whether they're an exploratory learner or they're somebody who likes to go through tutorials. How much freedom do they need in their process? That will change over time. So this isn't a question that you ask once and then it stays answered. Are they comfortable pairing? Would they prefer to work alone? Do they like to think out loud? These are all important questions to ask yourself when you're thinking about how you can most effectively help them. And then I mentioned this earlier, but I think it's the key thing. And this goes back to the key thing as the accelerant. We're gonna talk about morale maintenance. I want to reinforce how important it is to know the signs of stress and to recognize when someone's ready to throw in the towel and give up and maybe need a reprieve or take a break. I can't overstress the importance of this when knowing when your mentee may need a boost, a compliment or a sympathetic ear. Knowing when they're ready for a bigger challenge or when they're ready for constructive feedback is incredibly important. So again, you're the accelerant. Another way to think about this is that you may be the bellows to their fire. Remember, they are the fuel in the spark and we are providing air to help accelerate their growth. If we give too much air, if we give two challenges that are too large, we can blow out that spark and burn them out, right? Or if we don't give them enough air, we can starve them of the oxygen. They need to be effective. So you wanna provide the right amount at the right time and that's sort of the thesis of this talk. So I had some general mentor advice I wanted to cover as well. I talked to them in the beginning about it being altruistic and you being sincerely invested in their goals and their efforts, but I also think the relationship does need to be reciprocal. And the reason why is that you're learning from them as well and if you're gonna be consistently working with them over time, there has to be some value that you're getting back out of that. Again, you're giving without an expectation of receiving anything, but if the relationship's gonna last over the long haul, you'll find that you're helping each other grow and it becomes a positive feedback loop. One of the cool things about working with someone who is less experienced is that there's something called the beginner's mind. And Richard Schneemann recently wrote a blog post, I think a week or so ago, about a typo that has existed for four years. I think he said it underwent over 19 revisions and this was in some documentation that he had written. It had been seen by multiple editors and it was not caught. It wasn't caught until someone new to software development was reading this post and caught it. In this blog post, he goes into details around it and it's a small typo, but it really highlights the fact that the beginners are struggling to distinguish between signal and noise and they have to focus. That focus that they bring to it is a much higher level than we do typically as an experienced person. We are taking shortcuts, this is normal, but it's something to remind us of the value of that focus that is important to think about. And I get value out of that and I find that to be reciprocal. You also want to think about their work ethic, that's very inspiring to me. They're working through that signal and the noise. Again, it's monumental when you first get started. If you haven't had the opportunity to mentor someone and you start doing it, they will ask a lot of questions and you'll be like, why are you asking that question? And then when you think about it, oh yeah, of course that makes sense, but here's the interpretation that you might want to take. So they're constructing that knowledge regularly with your help and their efforts to do so are very inspiring. They're struggling with the challenges of the magic phrase and the silly typo that when I first started developing software and I did not have someone who's more experienced that you have to fight through on your own, so as a mentor you can really greatly accelerate their growth. So be inspired by the efforts in tenacity, recognize their greatness for what it is, let it motivate your efforts to be better and to do better. Also another cool thing is that your mentees are going to explore more technology than collectively than you can do on your own. And you want to take advantage of that effort. You want it to allow it to inform your opinions and grow your respect for their efforts. Your guidance on dimensions to consider when they're exploring new technologies can help them out a great deal, but they're going to come back and report back and say, hey, I went and investigated this new tool called jQuery and it's a lot better than Scriptaculus or Prototype or whatever the other JavaScript library was at the time when that first came out. So one of my friends, a person that I'd mentored through his career transition to technology, tells me all the time about the new stuff he's working with and his career is now diverged. That's a perfect example of I facilitated his growth into Rails and Ruby and now he's regularly doing closure and functional programming and he comes back and shares a lot of that information with me and additionally he's also, it's my professional network that's growing as well, so that's another value that you can get out of that. I think it's important to touch on this, you have to mentor the whole person, we talked about you're not just focused on a particular skill, it's usually in the context of a larger picture and if someone is stressed, learning is impacted. When you're meeting with your mentee, you want to avoid transactional relationships, you want to avoid saying, oh, okay, what's your current problem? Let me solve that, let's move on. You have to think about the bigger picture. Maybe your mentee mentioned about some problems that they were having with a significant other or maybe they had a problem with a pet or maybe they were trying to sell their house, all of these things will impact their ability to effectively grow because they can't retain information when they're stressed out, this is normal. This is a picture of a zebrafish and there was a study that some scientists did where they trained these zebrafish in a maze for 14 days with a food reward and then they introduced some stress and then put them through their tests and they found that it drastically impaired their spatial and cued memory. If your mentee is acquiring knowledge and then all of a sudden they're stressed, you're gonna see their level backtrack a little bit and fall off where you may have expected to be in the past and that's normal. So it's important to realize that when you lend a sympathetic ear at those types of moments, it can be drastically impactful in terms of their ability to retain the information and maybe the current session that you're working in. Which brings us to how do you do that? How do you make sure you're addressing those concerns? This is something that I've heard about and numerous different avenues in my life whether it was software development or coaching and the concept of active listening and it's important enough to reiterate if you have heard about it before, we're gonna go through those steps and the first thing is you wanna pay attention and this is something that I constantly remind myself when I'm having conversations with anyone whether it's my children or my wife or coworkers at work that I wanna make sure I'm looking at the speaker directly. I'm framing myself to hear exactly what they're saying and I'm trying to put aside my distracting thoughts. So just like our mentees may be less effective if they're stressed out, the same thing applies to myself. So I wanna make sure I'm balanced before I go into a meeting with someone. If they're in environmental factors that are gonna distract you, you wanna try to lessen those. If your person gets distracted by side conversations, maybe not meet with them in a coffee shop. You wanna make sure that you're able to focus on their body language and you wanna show that you're listening. So I find that focusing on these notes as I'm working with folks even though I've been doing this for four or five years or six years, I still think about go back to these notes to help me remind myself to do these things as I'm talking to them. And I'm trying to use my own body language to make sure I'm conveying to them that I'm paying attention. I will not occasionally, I'll make sure I smile and I wanna make sure my body posture is open to them. I've worked in some cramped rooms with folks at times when I've been mentoring them and I'll make sure that I'm able to scoot my chair so that I'm facing them directly and my shoulders are relaxed and I don't have my arms crossed even if it's cold. Those little cues, I think about those things that add up. They add up over time and they make a big difference. You also wanna encourage them to speak with vocal cues saying yes, uh-huh, indicates that you're listening and that you're following along to what they're saying. Next, you wanna provide feedback. It's a good idea to reflect back to them what they're saying and summarize. What I'm hearing is you're saying that you're struggling with restful routes and you think you wanna do this one-off ad hoc route and let's talk about that. Or it sounds like you're saying that you don't like model specs because of X, Y, and Z. Taking that opportunity to reflect back what they're saying is helping them know how they're communicating and it's giving them an opportunity to course correct in the conversation. And you wanna ask questions along the way too. What do you mean when you say that? Is this exactly what you mean when you're talking about the route problem that we're having? If you summarize their comments periodically, that's a great idea. Note, you're not interrupting them though. You're deferring judgment. You're just clarifying and trying to finesse what they're saying to their intent. Interrupting is a terrible idea and I think that in our career, it's very, there's a forcing function and that computers are very pedantic. So we tend as software developers to become more pedantic over time. This is my personal hypothesis. And so it's important to remember that when you're mentoring someone, this is not the time for pedanticism. You actually wanna defer your judgment, make sure you understand exactly what they're saying. If you're interrupting to say, well actually it's not quite that. You're limiting the full understanding of their message and you're probably frustrating them along the way. So you wanna make sure that they finish saying what they need to say and that before you're asking harder questions. And you definitely don't wanna interrupt with counter arguments. So when you do get the opportunity to provide feedback, you wanna be open, candid and honest. Telling someone false superlatives or false compliments is not as helpful as giving them the harder truths. But you also wanna make sure you're, when somebody's starting out, they may make a lot of small mistakes. They may confuse rails and rakes commands, but there may be a bigger foundational issue that's more important. And it's a good idea to address those in small amounts and to balance out the constructive criticism with compliments. So you wanna make sure too that you assert your opinions respectfully while you're doing that. There's the concept of the golden rule where you treat others how you would like to be treated. That works most of the time, but I like a rule next level above that, which is treat them how they would like to be treated. Remember, each person is individual. We all have our different strengths and weaknesses. The best way to know what that is is to ask, would you like some feedback? On a scale of one to 10, how constructive would you like me to be or how candid would you like me to be? And sometimes you can ask, do you need me to help you solve this problem or would you like me just to listen and be sympathetic? It never hurts to be explicit about that type of stuff. So on to the bonus round, that covers a lot of my stuff from the mentor perspective, but I wanted to talk a little bit about being a mentee to fill it out. So how do you find a mentor if you're looking for one? The key thing here is to know what your own strengths and weaknesses are. It's the same side of the coin as a mentor. How do you find out what those are? The key, one key thing that you can do is you can ask, right? You can go and ask your friends, your family members, your coworkers, your peers, hey, how am I doing as a manager? How am I doing as a coworker? What do you find most valuable about my work efforts? And collect their feedback. I did this recently and I reached out to a bunch of folks and I was very impressed with the breadth of the feedback that I got. But what was very interesting to me is that there was consensus from all these folks who were not necessarily knew each other about certain challenges they saw and certain strengths that they saw. It was great to hear about the strengths. It was also humbling to hear about the challenges. And one of the things they said is, hey, you might spread yourself too thin. Sometimes I feel that I don't get enough value or attention from you. And so that's something I've got an opportunity to work on. So once you know yourself and you know where you want to work on, whether you're trying to augment your strengths or mitigate your weaknesses, you wanna make sure that you think of someone you respect as this person a highly technical CTO. Or you're looking up to someone who is an individual contributor who's very effective at what they do. They're humble, they're always knowledgeable. They always have time for folks, but then yet they somehow produce a great amount of work at the same time. Are they a gregarious coworker who can speak to anybody and they grow their professional network with ease? Or are they a project manager who asks excellent questions that keeps the work flowing across multiple different teams and ensuring that everybody always has something important and relevant to do? Once you think of that type of person, it's very straightforward. All you have to do is ask. You may ask for a formal relationship. You may want to start small and ask for help with a particular problem to sort of test the waters out. You may ask for regular meetings or you may ask for ideas. It's not a bad idea to start off with a compliment. Hey, I really like how you do X, Y and Z. And I would like to learn more from you. I'm having this problem. Do you have some feedback from me on that? That can be an effective way to go. Next I want to make sure to touch on remote mentoring because we work in an industry where we can do that. And it's very similar to what we... A lot of things are very similar to what we already talked about, but a couple of things are specific. One is that whenever you can, prefer the higher fidelity communication medium. If you can do video, if you can meet in person, that's great. If you can't, try to do it over video chat. If there's a lag in the audio in the video, then you want to just go to audio. If you're working on code together, you want to do some type of screen sharing. That makes the meetings a lot more effective. And when you're talking, especially if you're just talking over voice, make sure to smile. It helps you enunciate, and it comes across in the communication. And then it's also one of those things where your physical response will affect your mood. So maybe if you weren't quite as excited about the process beforehand, smiling will get you there over the course of the conversation. The next thing I want to point out is to make sure to maximize whatever program you're using to communicate with, if you're communicating with them. If you're communicating over the phone, get away from your computer so you can't be distracted. I call this cheating on folks. If I am working with somebody remotely and I start typing or something like that, I'm no longer giving them my full attention and I'm really not giving, doing justice to that communication. That moment I'm not giving, I'm not doing justice to them as a person. So if you are using a tool like Skype or Google Hangouts, if you maximize that and maybe shut down notifications, that's a great idea to stay more focused. So early in the talk, I left out one important reason why you should mentor. And I wanted to cover that before we wrapped up. And this is your call to action. So you're at a Rails conference and whether this is your first conference or your first Rails conference or your 10th conference, whether you have 10 minutes of experience or 10 years of experience, the growth of this particular community owes a great debt and a measurable debt to the open source software community. There's many folks who've put in many years of effort. And you may not be a person who's interested in doing, contributing back to the community via software development or documentation. And that's okay. But one of the things you can do is reach out and help out a Ruby friend and you don't have to be an expert to do this. You don't have to be perfect at mentoring. Mentorship is a skill just like any other and it takes time to become more adept at it. So you can just be one step further beyond than the person that you're mentoring and that works out okay as well. So that sort of wraps up my talk. I wanna make sure to cover some credits and thanks real quick before I go. I wanna thank the Four Athens Coffee Club and Athens Women in Tech organizations for allowing me to give earlier versions of this talk. I wanna thank Stitch Fix for allowing me to give this talk as well and give me the time to work on it. And friends and family who I cajoled and coerced into listening to me also give earlier versions of these talks. I've got a bunch of links here to folks, the talks that I referenced, the blog posts that I referenced and some other resources that I referenced for material throughout. Does anybody have any questions? That's a great question. So the question was what do I look for when I'm looking at a company to see if they're supportive of mentorship? Is that a great way to say it? Okay, yeah, that's a great question. So I started at Stitch Fix last October and this is gonna sound like I'm shilling a little bit but I aligned with it and I got super excited about it. I look at their job descriptions and I don't just look at my particular job description, the job that I'm interested in at the time. I look across all of them and read them and say, okay, what are they asking about? What are they talking about in terms of their values? Are they valuing people first? That's incredibly important to me and so that's how I would choose a job. I also do a little bit of stalking so if there's folks who are on the careers page, you can go check out their social profiles and determine what kind of folks those folks are to see if it's gonna line well and it doesn't mean that you have to, necessarily you have to find the perfect fit. In my opinion, you're looking for openness and you're looking for alignment to find if it's the right job for you. I heard of a company and a Slack organization that I'm a part of where they were advertising for folks that you could come on board and you could be a, they would train up junior developers but it comes along with a contract and if you leave before the end of few years, they want you to pay back a certain amount of money and so in my mind, this may be a perfectly acceptable avenue for a junior developer if they find that that fits their context. I don't know if they need it, how hard, how dire their need is for a position but in my mind, the fact that they're saying, hey there's a transactional aspect to this relationship is a red flag and if I were in that position where I really needed a job and I needed to go into it, I would at least go into it with eyes wide open. So those are the types of things I would look for. That's a great question, thank you. Does that answer your question? Okay, cool. Any questions? Cool, thanks again for coming. I really appreciate it. Again, if you need to reach out to me, find me or find us over in the exhibit hall.