Alright. So just a couple quick announcements, this is a live show. You can ask questions with the hashtag #jsAirQuestion. We welcome you to do that. And it's fun to interact with those of you who are watching live. And we are a weekly show as well, so you can look forward to tuning in next week as we talk about managing dependencies like a boss. Sunglasses emoji. (laughs) That's the official title of the show. And we have a couple awesome people to talk about that, Ben Coe, Ashley Williams, Stephan Bonnemann. Interesting show. I'm excited to talk about this really important topic in our community. And that's pretty much it. And oh yeah, always follow us on Twitter, Google+ and Facebook those important things (laughs).
Okay, so let's introduce everybody that we have for the show. So again, my name is Kent C. Dodds. I'm your host every week and I love being that. But we have four awesome guest with us today who are great mentors and have some important thoughts on the subject. First, Taras Mankovski.
KENT: Sorry about that, Taras.
TARAS: It's okay.
KENT: And Jed Watson. Jed is muted, but he said hi. I saw his lips move.
JED: Hi! (laughs)
KENT: (laughs) And Kim Crayton.
KENT: And Colt McAnlis.
COLT: Hello! How's everybody doing today?
KENT: So yeah, today we're going to be talking about mentoring with these fine people. But let's get a quick intro to (mumbles) so we know a little bit about our guests. So we'll start out with Taras. Can you give us a quick intro to yourself?
TARAS: I'm an EmberJS developer. I have a company called EmberSherpa and we help (mumbles) be better at Ember. In the process, I mentor developers myself and we mentor developers for companies as well. So we do a lot of helping developers go from either no Ember experience to being fully effective Ember developer, so it's something that's very close to my heart.
KENT: Fantastic. Thank you. Jed?
KENT: Fantastic! Thank you for your work. Kim?
KIM: Hello, everyone. Good afternoon, good morning wherever you are. I am an educator by trade. I write curriculums. I train adults. I have trained people from the ages or worked with people from the ages of five until almost dead (laughs). So I am on the learner side. Also I spent the last year and a half trying to teach myself to code, so I come from that pain point. And so in my life, I was trying to figure out what I could bring from the things that I knew as an expert to this field. And one of the things that I said again was a pain point that I saw was in need was effective mentoring. This is a very open community. Some of the guest have said everybody's giving stuff away, you know, open-source. What other to what other industry just gives stuff away? And so people are very generous and they want to help. They just don't know how or they don't know how to do it well. And so that's what I've been speaking about and I'm writing about and just helping that process. Helping people better support learners and helping learners know what their process is. And it all came from a blog post that I wrote on my blog that said, "Stop lying to newbies." Please stop telling us this stuff is easy because it's not. And so that's how all this started for me. That's why I saw that I really fit with my knowledge of working with learners and helping them and helping boot camps and whatnot better create processes that support learning. And mentoring is a major part of it. That's me.
KENT: Thank you! So, great. I'm excited to talk with you. I think you'll have a unique perspective that you bring to the show today, so thank you. Colt, can you give us an intro to yourself?
COLT: Howdy! My name is Colt McAnlis. I am a developer advocate at Google, which basically means it's my job to get yelled at when people are using Android products and they don't work that well or at least from the developer perspective. Historically, I actually have a background in the gaming industry. I worked on a lot of franchises from Microsoft to Blizzard to Petroglyph and what not. I also had a stint as an adjunct professor at Southern Methodist University for about three years. And yeah, I guess my main focus on mentoring is both external, because of the main point of my job is to help developers work with our content better, but the thing I'm more proud of is the internal stuff. So you know, making sure that we're onboarding people the right way, getting them the right skills to be successful, making sure they understand the right way to move up the ladder and how to be proficient in a corporate environment and how to focus on the right things. When to say no, who to say no to, how to say no, what projects they should focus on. All the fun stuff of being in a corporate environment.
KIM: I'll start because that's one of the main-- I'd talk about what mentoring is what mentoring is not and how to make it effective. Mentoring is not Stack Overflow. It is not Slack. Those things are "I have a fire to put out and I need help right now." Those aren't mentoring. Mentoring is a relationship. It's something that's cultivated. And like any other relationship, if you value it, you put time and effort into it. So that's one the hiccups that people have when they desire to mentor is they don't realize that it's relationship part. It's the consistency. And so what you'll have is a newbie who someone says, "Yeah, I'll mentor you." And then the mentor, when life gets complicated or whatever and they just drop out. That works on Stack Overflow or I mean there have been times I've been on Slack or Stack Overflow asking a question and it's like they just leave. And it's like, did they die? We were in the middle of a question. What happened? I mean they don't answer it. And that's not what mentoring is. It's something someone who takes the ball and builds a relationship because learning is very complicated. People are very sensitive when they learn, especially when they're adults and they need that relationship built to feel safe so they can make mistakes, so they can ask questions. But mentoring is, again, I'm trying to really preface is not that one-shot off thing. It's a relationship that helps the mentor and the mentee decide together what the end goal is going to be and they work together to get to that place. So yeah, it's a relationship.
KENT: Well, any other thoughts from others?
TARAS: I just want to say that I'm really, really glad that Kim, you described it this way because I think it's exactly spot-on. I would add a few points to it but it I think it would all extend to what you're saying, so I think I think is really with a great summary of what mentoring has been from my perspective and what I'd like people to think of mentoring as.
KENT: And I totally agree as well but we're not undervaluing the importance of people helping on Stack Overflow or Slack or whatever. That's all really important stuff, like, keep doing that. But what we're talking about here is that relationship that you build with individuals who have their own struggles in their own lives and are working through the process of growing. And the other thing is I think that mentoring isn't just for the beginners or it's not just for like new people in the industry. There are people who have mentored me. Well, I kind of sort of feel like a beginner in the industry too, but I feel like everybody's a beginner at something. Even if you've been in the industry for a while, there are some things that you don't know. And so regardless of your circumstances, you can be a mentor to anyone and anyone can be a mentor to you.
JED: I think I have a kind of a complex relationship with the concept of mentoring. I don't really often walk around using that word or thinking of myself as a mentor, but Max Stoiber actually tweeted me into this discussion. I was like, "Yeah, that makes sense." We had relationships which everyone has mentioned, so far are kind of the key of this, I think. But also the concept of helping. I mean I feel like I have been very lucky so far. My dad got me into programming when I was in the middle of high school and help me start my first business and everything that I've done since then has kind of snowballed from there over fifteen years. And you know, I was lucky to get into tech. I was like to have someone to help me. I've always been surrounded I guess by people who have mentored me.
And then you get to a point where you realize that you've got something to give back. And it's just this natural shift that happens. So you start realizing that you know, "I can go and I can spend a day at a NodeSchool." And that's a very short a sort of brief amount of helping. It's also very intense experience. And then every now and then, you meet someone who sort of will follow you up and you can help them. And then there's a much longer term mentoring where you've got somebody who might work with who you can actually help progress. And it just feels like this nice holistic circle where, you know, I guess the word I'm dodging around is "privilege." And I feel like the right thing to do with that is then to pay it forward. Now, I can never easily go back and repay in kind of the people who helped me but I can turn around and do things that help other people and that ideally just continues.
And you know, you never know where relationships are gonna go. You know, every single person is a complete person. Just because someone is new at something doesn't mean they're not very experienced in other areas. And two ways it sort of stands out from my business in the last couple of years, one is that we've had a couple people at our developer accelerators and these people they've been through three months of learning how to be developer and they are very good with all the trending topics. And then you know three months and you're actually not a developer. It takes a lot longer than that to build the maturity that helps you become a good programmer. So the people who are dedicated to that, it's worth dedicating effort to help them on that journey. But they're also you know, fully formed human beings who are very good at a whole lot of other skills. And one of the things now businesses has been sort of allowing people to be leaders in one area whilst they're still, you know, kind of babies in another.
The other fun experience I've had is I got this email. I hope he doesn't mind me mentioning this but a couple years ago, from this kid, seventeen-year-old lived in Wodonga had a really interesting looking open source project, wanted a job. His named Sebastian Mackenzie. I was like, "Yeah, I'm gonna take a chance with this guy and see what he's like. Maybe we can help him. You know, he is obviously really enthusiastic." So he came and work at our company for about six months with this scrappy little project called 6to5. Obviously, that's a well-known story now like sort of where 6to5 went and where Seb went. And you know, in this very short amount of time, I learned a ton from him. That was nowhere near the kind of mentoring relationship that I was expecting. And I just ended up with a friend instead who's very much a leader in this community that I'm part of. Like he's gone like this. And I think that's the value that you get out of it is not just sort of helping people but also relationships that you build and the impact you can have that's greater than your own experience of it.
KIM: And that's what I want to speak about is it's reciprocal. Because we're adults, it's not like mentoring children or young people where it's all focused on them. When you have an adult relationship as a mentor, there's a lot you can-- it's like you switch roles a lot. Sometimes you're the mentor, sometimes you're the mentee. I mean it switches role. And I commend you for bringing in people who have other skills because that's one thing I hear a lot from my fellow newbies is, "I have this. I'm not fresh out of college. I've had this experience but nobody will take that in exchange for teaching me this." That's the frustration. It's like you feel like you have to start all over again. But I have something of value. I can do your accounting. I can do this. I can do that. I'm just asking you to help me-- because it's like bridging the- the Grand Canyon between ending the boot camp and being junior developer ready. And that's the lie. Stop telling people that once they've done that, they are junior developer ready because they're not! I mean if you give them a coding test, we freeze, like, "I don't know what that is." And so it's we need somebody to take our hand and help us through that Grand Canyon, to get to the other side. But I have value while you're doing that. I'm not just a leech sucking off you. I have something to give back.
JED: Yeah, I couldn't agree more. I mean, sorry I'm just gonna take this route and Kent, can put me back on topic at any point but we keep evolving the way that we bring-- we've got four people, three of whom have come from developer accelerators and one of them is self-taught with a couple years of experience working at (mumbles) at the moment. And the first couple were, you know, pretty scrappy on our part not on theirs. They sort of put a huge amount of effort in and rocked out with the right attitude. And then we put them on these like kind of easy, like simple like less important projects where there was more room for them to kind of learn and make mistakes. And that's outright it makes total sense until you've done it and then you realize it is the wrong way to get people in.
And then for the last two people who have come in, we've flipped it around and we've actually brought them in this QA because they were methodical and intelligent. And in that process, rather than being on the front foot immediately, they're actually assessing my work. And they're assessing other members of the team that got to be across the whole project and understand what it means to develop software and develop quality. And that level of responsibility and integration, we have obviously juniors, if anyone who is listening is thinking about getting us to build something for them (mumbles). But sometimes we have these people you know checking stuff and actually pushing it live to servers. It's a lot of responsibility but it builds a huge amount of confidence. And so instead of trying to get them working on unimportant stuff, we have them working on the most important stuff but it's things that are completely within their capacity.
And then over time, what we find is that we lose our QAs because they start looking into why an issue is happening. They learn more about how the senior architects are writing the code and they go (mumbles), "I think I know why this is happening." And they can follow these threads. And then, "I actually think I know how to fix this." And then you get a PR and then all of a sudden, they're so busy sort of submitting PRs that they're way too busy doing valuable development to just be running your QA anymore. And then you repeat the cycle. And it kind of plays to building confidence. It plays to creating a sense of value. And people are going to learn best when they're comfortable, when they're confident, when they feel like this is all working holistically. If you just kind of put someone something that's obviously less important, then yeah, of course it's not gonna work, you know? They're junior. We don't use "junior" and "senior." We sort of try and shy away from those labels. And yeah, like creating that space, we found it to be this much more successful way of you know-- alright someone else take over. I'm done.
TARAS: Yeah. Just to build on what you're saying, one thing I noticed recently, I think or six months ago is that because I used the word "mentor" quite a lot and then at one point to realize that I've been looking at it in a way kind of self-centered. Because what I realized is that my role as a mentor is really creating opportunities for apprenticeship to happen. You know, it's basically creating a structure that allows a person to go through the kind of the flows of acquiring knowledge and acquiring comfort, and building their legs you know, being like kind of building their both legs of development. Kind of getting the confidence of saying, you know, "I think I can figure this out. I have enough background to be able to figure this out." Like I think one thing that I'm hearing from Jed, what you're describing is going to describing a structure where people can evolve from or grow from a position that is-- you know, QA tends to be like you you're checking as opposed to you're making, right? It sits slightly different mental problem process. But I find that my role as a mentor now, a lot of it is about (mumbles) person to grow from where they are to where they want to be.
So if you permit me a couple more minutes, I can kind of (mumbles) how I've been doing that. One thing that's very special about EmberJS as a framework is because it's very conventions-based. It's a lot easier for me to say to a person like, "This is how you could do something. This is how is kind of the right way of doing something." And so the way we've been applying this is I have some apprentices that started off essentially learning Ember, but it kind of became really obvious to me that unless you're doing something significant, you never really learn, like you don't have good incentive to learn. And so one of the structures that I started putting in place is connecting them with like, making it possible for them to work with open source projects like HospitalRun run to contribute to their projects. So one of the my apprentices, his first real work was to write on acceptance test suite for HospitalRun. So that's you know that I had to create a connection with HospitalRun, you know, kind of get them to say, "Yes, I think we can do this. Let us enable you and your apprentice to build this test suite and then get it to a point where its mergeable." So going through this process, like we've done a few of these since then and now he's working on the client's project doing, open sourcing a client's project. But it's been like I can see over the last six months, the person going from, "I'm really not understanding what's going on" to being confident that they can be responsible for certain aspect of development at least.
KENT: I like the theme of developing people's confidence, that they could do it. Because just like Kim said at the beginning, this is not an easy industry. It's easy to ask now that we're used to it now and so I like it seems intuitive and natural and easy. But really, like if you think back, it was not easy. I remember the first time somebody tried to explain to me what a string was and I was totally lost. So yeah, like we can all remember during our early days, the difficulties.
And so I want to touch back on what Kim mentioned about how we all come with existing skills. Like we may be babies in our experience with tech but like maybe we're coming from previous industries or we all have different kinds of skills and we all bring different things to the table. One of the biggest things I think we bring to the table or one of the most common things that we all bring to the table is our different perspective. And I think that's a really important aspect of, you know, I've talked about this a couple times about the hiring process that we always seem to leave out, right? When we're hiring a developer we're putting them up against the whiteboard and having them do a bunch of these silly problems that they'll probably never have to come across. And we're trying to identify "do they know the thing that I've contrived up?" You know like, "do they know this random factoid?" What we should be doing, and this is a little tangential so I apologize, but what we should be doing this hiring process is identifying what can this person bring to my team? What is that that they already possess that they could bring? And then also identifying, "Can they learn the additional things that I need them to be able to do?" And most people can most people can. Most people can learn those things. So you should be focusing on what can they bring to my team.
I'm not gonna go too far into this but somebody asked me a question about how I do hiring, how I interview. I mean it kind of follows this vein. So I'll add a link in the show notes but I think that's a really important aspect that we need to remember everybody brings a different perspective to the table and we should consider the perspective as well as other skills that people are bringing into our companies.
KIM: And the one thing I'm going to say, I mean I'm a black female. Tech has embraced me. I am so thankful to tech. I get so many opportunities because people respect my perspective. And I agree with you, hiring needs to reflect that. You know, you're encouraging people to come into tech, make it safer for them to stay in tech. That's the issue. You know, you have a thousand people every day coming into this field, but will they stay here because do they have the support they need to become the developers they want to become? And I wanted to touch on one thing that you mentioned before, and I know I have to talk about this is, impostor syndrome. Because I just really want to address impostor syndrome. And I put in the show links a link to code newbies podcast about impostor syndrome because she's done research about impostor syndrome and I'm just going to give you my take on what's impostor syndrome and what it's not.
Impostor syndrome is a person who is skilled at doing something and still believes they can't do it. A newbie is not experiencing imposter syndrome. You would not tell a newborn, "Get up and walk or you're an impostor!" No. (laughter) They have to roll over first. They have to scoot. They have to crawl. There are different steps is so many-- it frustrates me only because I've talked to so many newbies who beat themselves up because "Oh, I have impostor syndrome." No, you don't! You're learning. Learning is difficult. And if the industry would stop saying how easy it is to learn to code, you wouldn't have that disconnect. Because what happens is someone leaves a program and then they can't do it and then they internalize it. "It's me. Something's wrong with me." Because not enough senior developers are saying, "You know what, it took me two weeks to get my dev environment up as well." Just being honest about those things helps us a lot because we like, "Oh, I'm not stupid. It's not just me!"
Every time Kyle Simpson puts something on Twitter about the fact that he had to restart something over, oh my god, he gets so many retweets for me. Because I appreciate, people know who Kyle Simpson is and if he can say, "Hey, you know what, I screwed this up. I spent three weeks on this and this is just not gonna work. I need to start over," that's the stories that we need to hear. And those are the stories that mentors need to tell their mentees so they can feel comfortable, so they could then also helps build the relationship because they're like, "Oh, you've been there too. I can empathize. Man, you know how hard this was when I was doing this in college? Blah, blah, blah." Those are the things we need because that helps us persevere. If not, we feel-- because let's face it, most of us are learning on our own. Most of us are not going to boot camps. Most of us are learning this on our own because the information is out here free, so we need support. We need those people that say, "You know what, you're spending too much time on this. This is how I would handle that problem. This is how I do that," because we don't know.
KENT: That was fantastic! Highlight of the show. That was awesome.
JED: (laughs) Absolutely. And if I can riff on that as well, Kim, I think something you touched on is that the diversity factor. You know, diversity is not important because it's a metric that we should be hitting or because, you know, people say it's important on Twitter. And you know we all believe this now. It's because having all these different perspectives, all these different experiences is super valuable. And there is no way that I can have anything like the experience that you've got and vice versa. But by working together, we can understand a lot more and we can address a lot more. And that is really cool. We're not going to get that without effective mentoring. Like, we've gone from talking about how we mentor or what mentoring is like, but why? Which is probably the best thing. Mentoring is valuable because it increases the scope of our community in such a good way.
I don't know what it's like where you all live, but in Sydney, everyone is looking for seniors. And you know, if you've got enough experience, you can walk in anywhere and get a job y'know? We're lucky. It's a good industry to be in right now but no one wants to talk to the juniors. No one wants to talk to people who just like (mumbles) but just haven't got the experience. It's fine. Support them for a couple years, if it takes that and all of a sudden you've got a great developer and you're growing the community, you're growing the pool. And this is the only way we are going to fix this. This is only way we're going to more women in tech is by not just saying, "Hey, we want you!" And we do, by the way. "Please come be part of this. We're having fun. It's good and you're welcome." But then also supporting that process, by having effective mentoring, by having not just an inclusive attitude at the, "yes, nice to see you at the (mumbles)," but like an inclusive attitude in the, "I will invest my time in helping you do this, because that's what I want to be creating here."
KENT: Yeah. That's great. Just to kind of go off that a little bit, I meant to mention at the beginning of the show what inspired this, the show, in the first place. And a couple weeks ago, back in June, I just had like one of those showerthoughts where I was like, "You know, I wonder how many people in a third world country, who, if they were given the same amount of opportunity that I've had, would be wildly better or more skilled at software development that I am?" I'm not trying to compare myself to anyone by any means, but just like that thought of I've just been so blessed with so many opportunities and again it's that work privilege. I've been really privileged to grow up in a country and in a family where I've gotten these opportunities.
And somebody, his name is Lennex Zinyando, I think is how you say it, he responded and he said, "I live in Zimbabwe, a third-world country. We have a lot of gifted developers here. Most lack mentorship and opportunity." And that's when I realized, and we have kind of a conversation. I'll post a link to this tweet but that's when I realized like, "Yeah, we you know, many of us have this privilege and feel that moral obligation to give back what we have, you know, not earned or anything we're gifted with this. You know, we feel like we want to give back, but often, we don't know how. And so on as part of you know, the last couple of minutes or twenty minutes that we have, I would like to talk a little bit about how. Because I think lots of people feel like they want to help and they are in a position that they can, but they don't know how they can help.
KIM: Can I start there? So for me, what I tell people is to make it easier because the mentor needs to really assess their time, their talent and their temperament. Everybody can't be a mentor. We need to just be honest. Some people just are not good for newbies. And that's okay. You can help somewhere else. But if you're going to make that process difficult for a new person, you just don't need to be there. But the ones who do, so if time is an issue, those are the things you need to be honest about with yourself. But project-based learning and you're working on projects already, and so that's why one thing I liked about what Taras and Jed said, they're already working on projects put them on projects and have meaningful projects because those things are objective and not subjectible. So the mentee, again, we don't know what our skills are because we've taken this course that says "we're junior developer ready," so we think we know it until-- but if someone says they want to be a front-end developer or work on an open source project, you can give them very clear directives, "You need to be able to do this." That's very of objective. If they can do it, you move to the next thing. If they can't, you step back and you scaffold until they can. It makes it very easy.
Mentoring has to be planned. It's not something that you can just throw out there because then it become-- it takes up too much for your life because there's just no structure to it. It has to have a structure to it. But project-based learning is the best I've seen the best way of learning this stuff. Because we're working on projects anyways, so it really simulates real-life. But it's a really good way for mentors-- in particular, I've had a lot of mentors like, "I want to do it but I don't know how. I don't think I'll be good." Give him a project. Either they can or they can't. If they can't, you should step back down and get them skills so they can do it. If they can, you just move to the next thing. And that's how you build those skills. So having them on QA or either technical writing also helps because they're reading stuff and they're learning stuff. Put them on certain things that really help them to learn those skills but something that you can assess because it's measurable.
TARAS: I want to build something on top of what Kim and also Kent. I like to fill in a bit of the story about Lennex because Lennex is one of my apprentices, so I have a bit of an insight both from personal-Lennex was one of my first kind of personal apprentices whom I've worked with over a long time. And then one thing that Kent sent about what it means to be a mentor, one thing I've found is that when I was working with Lennex, for the first like months almost, maybe four months, I was getting frustrated because he was making very little progress. And I think what-- it really dawned on me. It only actually occurred to me about six months into working together, when at one point, I realized like I asked him, "What kind of computer are you using?" And he told me, "I am using Linux." And I'm like, "Oh well, I actually need you to have a Mac, so I'm going to send you a Mac so you'll have something to work on." So I sent him a Macbook and he sent me back a picture of the computer he was working on. And it all made sense! I can understand why he didn't have-- he was not able to like why our hangout sessions were so frustrating. His computer was ancient. He had he practically had holes rubbed into you know the part where your palms go, like that part was completely rubbed off. Like his computer he was working with was really old. And so you know, here was like getting kind of irritated with the fact that he's making so little progress and never even cared to take a second and ask him like, "Well, what kind of computer are you using?" You know? So that was one thing.
And then the other part was when we work as engineers, we make this assumption that everybody has engineering background. And you know, not asking that question is so flawed because when I asked Lennex, you know, "What were you doing three months into us working together?" I'm like you know, me helping him, I asked him, "What did you do before?" And he's like, "Well, I used to make websites." You know, making websites making websites with like WordPress is different than engineering software systems. And so really, you know, I realized that now looking back from what I've learned, one thing I see is that it's definitely possible for somebody who doesn't have an engineering background to learn to become a good software engineer, but it just takes that much longer. And so with Lennex, that you know, the path for him now that he's actually contributing-- he's actually able to do work and be productive with Ember, his next step is to go back and do like computer science and software engineering courses just to build up his foundation.
KENT: Actually, I want to ask you about sending him that MacBook. It sounds like it was like really game-changing for him, obviously. So if I were a mentor in that situation like I might be wondering, after hearing you say that, I might be wondering, "Well, I don't have enough money to send Macbooks to everybody in the world that I want to mentor." How do you manage the finances of that kind of thing? Like I imagine you don't need to send a MacBook to every person you mentor but how do you manage that situation?
TARAS: Right. So it's good it's getting easier now because some of my apprentices that you know, I mentored are now have jobs. So I just recent only when I was in India, I met a cab driver who told me that his daughter wants to go into computer science but she doesn't have a computer. So you know, I sent a tweet out and that's saying like, "Can we pool some money together to get this person computer? For this girl who wants to become a computer scientist." And you know two of my apprentices responded and I'm like, "Oh, that's so awesome!" (laughs) This two people that I helped and now helping me help somebody else. And so it gets easier. And as you build up the structure to do that. But again, I think I'm also fortunate in that I'm able to with the kind of consulting that we do, I'm actually able to give some of my apprentices real client work to work on, so I can bridge that gap between their learning and their first gig. And then that allows me to recoup some of the money that I invest into a particular apprentice. I try to do my best to kind of create structures for that to happen.
KENT: Great point. Anyone else have other thoughts on that?
COLT: I'll try. Sorry for being so quiet as the disembodied head in and hang out.
COLT: So there's a lot of themes here and kind of one thing I'd like to do is just kind of bring it back to its core. There's a lot of talk about you know bridging that gap from low skilled individuals to high skilled individuals and about opportunities and about pair programming and junior administration and things like that. At its core, the way I like to view mentorship is it's about providing experience to create clarity. At every part of it, it's that 10,000-hour rule by Malcolm Gladwell. I mean, we can all sit down and find a compiler and deal with it but when you have that person standing next to you showing you what to avoid in the great swath of things you could focus on, you become more efficient.
Now when you asked about how do you apply that, something that I've always kind of guided myself by when choosing mentorees because that's a process in itself, much like not everyone can be a mentor, not everyone can be mentoree and it's very important that you find the right match between mentor and mentoree so their goals are met. But when I look for a mentoree, I find someone who has a clear goal something, they clearly want to do. And quite frankly, I try to look for people with chips on their shoulders. I want people who are passionate enough, that they're going to really dedicate themselves to achieving a goal at all costs. And if that's the case, then my responsibility is to just help them stay focused on that and help them avoid the land mines of things that are going to keep them distracted or keep them from achieving that as fast as possible.
And to be clear, this doesn't just happen at the inexperienced level. I mean, I personally get mentoring and I've been doing this you know, twenty something years now. You know, I have personal coaches. I have people at my same level that have personal coaches. And it's for every part of that swath of the skillset, not just engineering. One of the biggest mentorship opportunities that were missing across the entire tech industry has nothing to do with code, it's how you interact with other people. How you lead up. How you deal with starting a project, gaining consensus for it, finding other people to follow you behind it. It's a very entrepreneurial process in modern technological industry and most engineers that were turning out understand the syntax but don't understand human factors involved. And so with every part of this, when you take someone as a mentoree, your goal is to keep them from being distracted by things that aren't helping them achieve their end goal. And then helping them build relationships with other people and understand how to foster those relationships so that they can then become self-sustaining overtime.
JED: Colt, you can just keep talking for the rest the episode if you want. That is brilliant!
KENT: (laughs) We're waiting for you, Colt. That was great. Anybody else wanted to go off on that? Sounded like there are a couple things in the chat.
KIM: Yeah, I was typing the four c's. You hit right on it, Colt. It's the being able to collaborate, being able to (mumbles) creative thinking, critical thinking and communication. Those are skills that-- I work with Millennials and people think it's just the Millennials that don't have it. It's a lot of people. And it's a lot of people in tech because that's one of the reasons some people got in tech. They'd a rather not have to deal with other people. But it's also everything is about relationship. And how do you get your teammate to buy in on this line of code if you don't know how to communicate that well. How do you solve the problems if you're not a creative thinker? If you're too afraid to step out there. And those are the things that that I, as an educator, constantly taught my students. Math, Science, Social Studies, that comes easy to a lot of people. It's the human factor, as you just mentioned, that did just kills them every time. They don't know how to do these things. A lot of people don't even know how to go approach, how to even get a mentor. They don't know how to network. To them it's passing out cards. There's a whole human factor that a lot of people are missing. So thank you for bringing it up, Colt.
JED: yeah. I'd love to riff on that as well into the open source space. I think you know mentorship at a company or in a particular environment or even if you're in a position of teaching is kind of one thing, but another aspect of this is positivity and the understanding, particularly when you're working across international borders that people come from different cultures. I kind of have to check myself often that if I'm talking to someone on an open source project, you know what, there's a really good chance that they're speaking my language and I can't speak theirs. And you know, people will respond to tone. Tone is very difficult in text. Tone is even more difficult in text when you've got this language barrier and a cultural barrier, making it harder. I have enough trouble with tone with people who literally sit next to me. You know, I'll say something and it would just come up the wrong way, particularly with junior people. Because I might make an offhand joke and they will take it and you know, read something completely different (mumbles) is their judgment? Should I be concerned? Did I just do something wrong? I catch something like, "By the way, this is what I was going for (laughs) when I said that. And if it came out this other way..." you end up over compensating but it's still really important to do that.
And I see these blow-ups happen where someone will say something on Twitter and all of a sudden, you know, fifty million reply two weeks later and you can't even follow the thread anymore. It's just gone kind of sideways or backwards or ruin someone's day. And the worst thing you can do is ruin someone's day because you don't know what they're feeling, you don't know how they're interpreting it and you know, it's easy to then kind of how things escalate. And you just need to de-escalate constantly. You need to provide opportunity for people to pitch in and say, "Oh yeah, hey, the way you read that was not the way I intended it," rather than getting aggressive because now they feel like they're under attack. This happened a couple times just like last weekend and the weekend before around to two open source projects that I care a lot about. You keep it respectful and it is like someone will (mumbles) and then someone else will (mumbles) and like you know, you end up with someone who's just unproductive for the next couple of days. And how does that help anyone? Where you it costs you nothing to assume positivity and reply with that or to be kind, basically. And I think that's sort of a really important part of particularly in a mentoring relationship, you're in a position of power whether you feel it or whether you intended to take that on or not, you are. So always be aware of how someone else might be interpreting you. You're used to having (mumbles) feel about yourself and you're used to peers and friends who look at you and think, you know, they know where you've come from. And then you start mentoring someone and suddenly, whether you want them to or not, they might be putting you on a pedestal. They might be looking for approval. They might be afraid of judgment. So this is sort of a really important thing, I think, to keep in mind.
KENT: Great. Thank you. So we're coming down our time. Are there any other important things that we should keep our mind before we get to our Twitter questions?
TARAS: I just want to say one thing for advice for apprentices. Like for me, personally, if you want to for me to mentor you, have to be really persistent. Most of my people that I have mentored, they've asked me like six times before I was actually really able to spend time with them. So I think in this case, be a little gutsy. It's going to go a long way because people are really busy and it could be really hard even if we want to. Finding the right apprentice could be really hard but if someone is dedicated and showing that they really care about this over time, it really goes a long way to showing that yeah, this is the right person for me to invest time into.
KENT: Awesome. Great. So we do have two Twitter questions. If anybody's watching live and has a question they would like answered the hashtag is #jsAirQuestion. The first one is from Wilson Rondini ?and the question is, "Mentorship is often used as false advertising. Galvanize as well as employers feign mentorship. How does one know if truthful?"
JED: Can I take this first? This is a great question. And this kind of hits me because you know we get off and we talk about jobs (mumbles) we didn't mention mentoring. I think you can absolutely look for like evidence. If you're doing something and it's authentic, it should show. The senior position I mentioned right at the start of the episode was that we actually have, the last five months, employed someone very senior as-- we created position for them, we call it developer in residence to come in and teach, particularly the more junior people but also to influence the company culture. And so, this is some sort of an observable thing, you know, who have you got working on mentoring? Is it just like something that you expect people to be able to do on the side while they're probably you know putting in big days now that they are on pressure or is it something that you've actually constructed a position and a mandate to do at a company level and at the cultural level? There's also external factors I think through evidence of participation in open-source, participation in community. These kind of things like there's a lot of visibility around this now. I can think of a lot of companies where I would be very confident in believing that they have a good mentoring culture purely on observable output.
KENT: Cool. Question answered. I think that was good. And Priyanka Kore asks, "If you work alone or in all beginners team, is there any way to find a mentor? Or what's the best way to do it advice on a certain problem?" (silence) It's a hard problem, I guess. (laughs)
KENT: I know that illusion well. Colt, did you have something to say?
COLT: Yeah. I'll just follow that up. I completely agree that the best chance you have for mentorship actually comes from your existing social circles, especially if you're new to a company or you have a new you know friendship environment. Getting introduced to people around you is the greatest way. There's actually a definitive tome on this if anyone's interested. Harvard business review has a fantastic book called On Getting The Mentoring You Need. It's like thirteen dollars or seven pounds or whatever. I saw it a couple weeks ago but basically it's a really quick hundred fifty page book that talks about identifying what your actual goals are, who potentially you can get to help you achieve those things, then how to go about building and fostering that relationship from a mentoree level. Really good read. I highly recommend everyone at every walk of life, even if you're the CEO of a company, reading this book because we all can improve and finding the right people around us to help that is the key to doing that.
JED: I can't really improve on the definitive tome but I think that the persistence has come up a couple times and for me, part of that is the commitment. There's probably about a million people out there that I could mentor at this point. And if you know like (laughs) that not a thing. That's not possible. I'm taking on a position of mentoring is a serious commitment as has been mentioned a couple times. And if you want that from someone, then impress them. You're not going to impress them necessarily with what it is that you want mentoring in. That's why you want the mentor, right? But you can impress them with your dedication to it or your interest or your keenness. We have you know our Rails Girls Summer of Code. We have a team contributing to KeystoneJS right now. And that's amazing. That's also a commitment they have signed up for three months to do that. So we take that seriously. We help them, you know, help us but also get the most out of that. So yeah that commitment I think is a really important thing-- find a way to show and that will help.
TARAS: One thing that I just want to add to that is unfortunately, a lot of this looking for a mentor is I think really risky. You can spend a lot of time and not really get a lot of results because you know it's kind of-- I mean there's no guarantees but there is one way to guarantee the (inaudible) you know, especially for (inaudible) as you know new developers learning, getting so one of these services could be a good way, a sure way to at least start to make some progress in your learning. Then you could also on the side be building a relationship with someone who is going to-who's not going to be associated with it as well. But I think it's worth pointing out that in situations where you're working for a company and you need support, there are companies that are set up for helping you. So that's also something to consider.
KENT: Okay, so we just have a little bit of time for this last question. It's actually directed at Kim, but I think anybody can answer this question as well. The question is from Natalia, "What resources do you offer to people in tech when they want to learn to be mentors?"
KIM: What services I offer is I do some speaking. I do some consulting. I also write about it but I do a lot of-- I've been working again a lot with boot camps to help them better-- people spend a lot of money for boot camps. And so, if you think you really make their environment really safe and know what the learners need outside of code, because people just focus on coding, syntax. That's not that's not what people need to become developers. Also, people are looking for projects. I can't say if this is an international site but there's one site called instructables.com that has a lot of different projects. So look for project-based coding projects. Those kinds of things. Look for code katas that you can work with together. And specifically, the code katas that start with level one. Code newbie has started creating code katas. They have a level one so that person who knows very little skills has value and they can come in and they can do something. And then it scaffolds up to level III. Because what I was finding is when we were doing our meetups, people who have very little skills, they don't have a place to get in. And so if you can create a space for the newbie who's just learning to feel valued and can get in and do something, that is meaningful. That person is going to like, "Oh, I can do this." And they just keep building on and building on. So there's a lot of things out there. Google is our friend. We know that. But again, it has to be planned. So Google projects, coding projects. I've been doing interviews for vetting candidates for developer positions and what I've had them do is explain, through YouTube videos, how they would solve a code kata. And that helps people understand their thought process. And then that's when you can see where your mentor has gaps in their learning. Do they know about this? Is this a tool they need to use? That kind of thing. So just assessing, having conversations. If there's not a black or white, it's a whole bunch of things. And we know that with tech.
KENT: Ok if anybody else has other resources they would like to mention, you can add them to your picks. That's what we're going into next. So this has been a really enlightening conversation, by the way. It's been wonderful, thank you. I think this is a good thing for the community so I'm glad we're doing it. So let's go ahead and we'll jump into our tips and picks. I'll go ahead and go first and then we'll let you all go.
My first tip is spread things out and reduce commitments. If you're feeling like you're getting close to burn out, I have recently been feeling that a little bit and so I've had like some conferences that I'm going to speak at. And they're asking me to do like two talks or something. I'll ask them if I can repeat a talk. I generally don't like to repeat talks if they've been recorded and stuff. I like to produce more content. But I have some talks I've already prepared that haven't really been recorded, so I asked, "Hey, could I swap out that talk that I was accepted for with this other one?" And it really just, yeah I'm much less stressed out. I also, like, this week is a crazy busy week for me and I think that it's important to not like line up everything at the exact same time.
Also another really good thing, this is kind of related to mentoring is try to make stuff public. Conversations that you have with people or things that you're practicing or trying whatever, make things public because you don't know who that could help.
And then my pick is react workshop by Matt Zabriskie. We're actually giving this workshop today at Midwest JS here. And it's a really, really fantastic workshop. Matt did a fantastic job on this, so I recommend you check that out. I'll also give links to my workshop sites for my Frontend Masters workshops. Those are available. And so there's really good resources for webpacking and open source in those. So that's my tips and picks. Why don't we have Jed go next?
JED: I had two, but after that last question, now they're three. My first one was a Typography.js. I've realized only yesterday how cool this actually is. It's basically a way to build like a very modern reset like stylesheet reset. And it's based around some very good typography concepts. Unfortunately, a lot of developers don't really get excited about typography. It's so easy to make your stuff presented better. Check it out. It's well worth the look.
My next one's gonna be KeystoneJS which is I don't know if this is cheating since it's my own project but I've literally been like went from a minor refactor into a react-based user interface, a bit over a year ago to like we have rewritten everything. And we are hopefully just a couple weeks away from this massive launch of all of the stuff that I've been working on for the last year. And I'm super excited. So check that out. But maybe in two weeks (laughs).
And finally, the other thing I wanted to give a shout-out to was NodeSchool. So just like as a resource. They're on all over the world and it's great. If you're looking for mentors, there are mentors there. If you want to try being a mentor, there are mentors there. You can go watch how other people do it and you realize very quickly that it's something you can do as well. And we've got, you know, someone who was just absolute junior beginner, I think like not a year ago, going to NodeSchool and realizing, "Hey, I actually know a ton of stuff. I can help someone. I can help everyone!" Everyone actually has the ability to mentor someone in something and usually, it doesn't take you long to have something that you can explain. So that's a really good place to go and actually develop that skill and experience or find you know a leg-up.
KENT: Great. Thanks, Jed. Colt?
COLT: So tip and pick. So my tip for everybody out there is a learn data compression. There's an amazing amount of movement over the next five years towards the next five billion human beings that are about to get low computational 2G connections across Southern Asia and South Africa. These people will come online and basically redefine how technology works for the next three to four decades. And quite frankly, we, as developers right now don't have enough mental cognizance towards what's required to really reduce things like data footprint, memory count and asset sizes. And so there's a ton of resources out there. If you're looking to operate in these types of economic areas, if you're trying to launch a website that's focused towards India or a new application to help out people in South Africa, you need to understand the basics of data compression. Not just because there's a new hit HBO show about it, which is funny, by the way, but because the fact that this really matters to changing the lives of billions of human beings moving forward.
And my pick, so riffing back on the mentorship angle, I firmly believe that everybody should take training on how to be a manager. Even if you're not planning on being a manager, the types of skills that you learn during that process helps you understand your management chain better and the ability to manage up and manage horizontally. And for that, there's no training I've ever been to better than UCLA's technical management program. Fantastic resource. It's a bit pricey but if you can get your company to cover it, it's really, really worth your time. It's probably one of the best trainings that I send all of my mentorees to on a regular basis. So check that out.
KENT: Okay. Thanks. Taras, why don't you go next?
TARAS: So my tip is if you learned something you probably know more than a lot of other people about the particular thing, so don't be afraid to be that person that knows something, even if you don't know everything. I think it's okay to give yourself room to consider yourself knowledgeable. So you know just like taking a bit of risk and almost like I think faking till you make it kind of really applies here. I'm in the works for me. I went from not doing any front-end development to being a senior frontend engineer two months into learning Ember, so like I know it's possible. You just have to be brave in some respects.
Now, the other thing I wanted to tell you guys about is so I run Global Ember Meetup. It's an online meet up for everyone who doesn't have a local Ember meet up and for everyone in the Ember community. And one of the things that we do is we run local conferences for places that otherwise could not get an Ember conference, so we have a Global Ember Meetup. We have this conference called GEMConf. It's happening in (mumbles) JS this weekend. So if you're in the area and you're curious about Ember, we're going to have a day-- a workshop introduction to Ember then a whole day of talks about Ember and follow-up with training. And if you're interested, we might be able to give some discount on training, so just let us know how we can help.
KENT: Great. Thank you. Kim, it looks like you have a whole bunch of links. Make sure we get those in the show notes. Do you want to give us your tips and picks now?
KIM: My tips are I do a commit to doing a daily-I call it mentoring minutes. I put it on Twitter and on my LinkedIn so if you follow me on @kimcrayton1, you'll see just some wisdom that I just think of that day. They're just a little one liner because they can only fit in 140 characters. Tips, get comfortable with being uncomfortable. You're learning. It's okay. It's gonna be frustrating. You're gonna get pissed off. It's not going to be nice sometimes, so get comfortable with that because that's what programming is all about, you're solving problems. And then find opportunities to teach what you just learned. It's a great way for not only you to give back as somebody who just learned something, so again there's that reciprocity switching roles between mentor-mentee but if you're able to teach something, you solidified your own learning, so that's a great way to do that.
My picks are, again, because I'm coming from this as a new person, so many people I know who are learning on their own are taking the Harvard CS50, it is a phenomenal class. They use the C language but how he breaks down computer science concepts that people who are learning on their own wouldn't get is great. And you can go to EDX. They have a free course. And if you take it on EDX, you can take the all the classes as well and you can turn in the homework, so you can get a certificate at the end saying that you've completed this course. And it's actually Harvard's most popular course in their whole school. So it's a great course they're offering online.
Also, Code Newbie is one of my babies. It's where I realized that I wasn't by myself. And so their local communities of code newbie and the whole our whole mission is create community and safe spaces. Also for getting women in code, one of the things that I love is women who code. It's not just for people code, it's for people in technology but they've been so supportive and inclusive and letting us you know, just helping women just find their place in tech. And I'm learning about open source but Hood.ie has been a great open source project and they're really supportive. And I love Gregor. And they're really supportive of newbies. And so I really want to say if you really want to-- because Charlotte's on there. Her twitter I think is First Pull Request or My First Pull Request, so they're really supportive of newbies. So if you really want to open source project-- and I'm sure there are others but this is the ones I know because I actually was doing an open-source, I did open source meet up here and Gregor came down to tell me, "Facilitate that!" just because there are people here who wanted to learn open source. So they're a great community.
KENT: They truly are. They're fantastic. Great. So that's our show. Let me just give a couple of closing announcements and then we'll say so long, farewell. We won't sing it. We don't have to sing it but (laughs). So just a shout-out to our silver sponsors ReactJS Program, it's a great way to master the React ecosystem. And Sentry is a cross-platform crash reporting, so check both of them out. They're fantastic and thank them for supporting the show.
So a couple links to forms that I'd love for you to go, jsair.io/suggest will take you to where you can suggest topics and guests for the show. Jsair.io/feedback so you can submit feedback on this show or other shows or the show in general. And jsair.io/email will take you to a place where you can sign up for the newsletter and get weekly emails with highlights from the show. With that, our next week's show is about Managing Dependencies like a Boss and we have some awesome guests on that show, so looking forward to that. And yeah that's pretty much it. So thank you very much for all coming. And thanks everybody for listening. We'll catch you all later!