 Some strategies to help you mentor new developers. First just a little bit about me, I'm Cheryl Schaefer, you might have guessed from the program. I was a flute teacher and a performer. I have a master's degree in music. Of course, being a musician I also worked a bunch of other jobs. I did photography, I was an optician, I worked for some dentists, I had a lot of opportunities to learn different domains of knowledge. I started in software by going to local meet-ups with my brother Chris, took a couple of classes at the local university, and then there was a meet-up that started in my town for women that I started attending. From there I got an apprenticeship at LaunchCote, which is a non-profit, I was working under Mike Many. I've been there for almost two years now, and I recently mentored my first hire. LaunchCote, the non-profit, is basically serving unemployed or underemployed adults, like working towards upward mobility, helping people get their first tech job, and offers a lot of free education opportunities. But I don't know if about me, let's talk about you, who could maybe use some help. It's hard to find enough people to help you, beginners cost a lot less, plus you can make sure they use the right editor. We all know that teams of people with diverse skills levels and experiences really do produce better software. You can build that team around you, and in part of that process you're going to learn and grow yourself. Kind of like metaprogramming, you set them going and they will produce more people, and then it just turns into this greatness there. I'm not going to talk about interviewing right now, but if you want to talk about how do you interview people without degrees and stuff, you can come catch me later. But say we already found someone, thinking of gender-neutral names like Chris, Pat, let's say we found a Sam, meet Sam. I know what you're thinking. What I really meant was any hobbit who would follow Gandalf. Sam is driven and smart and talented, but they don't have a degree or maybe it's something else. They went to a boot camp or a launch code class. Maybe Sam actually did a project in C-sharp or Java or something, and they don't know Ruby yet. You could probably get HR to give Sam a chance, but they're going to have to prove themselves and show that they can really learn and really do it. How can you help them be successful? One way is to build a learning plan together, especially if you've got someone who, like I said, did something else for their stack. So I think there's a couple things to this whole learning plan that I'd like to bring up first. So really, this is about Sam, this isn't about you as a mentor. And so everything you think about as you work with them is focused on Sam and Sam's choices. And maybe how Sam feels. They're most successful when they feel responsible, when they feel challenged, and when they feel confident. If Sam says to you, I need to do this, I can really do it if I try hard, I can meet this challenge. That's when you know Sam's going to make it. Also, it helps to be flexible if you can make your plan flexible enough to adjust for Sam's learning styles, and Sam's learning tricks are going to work better for themselves than yours will work for them. So you want to try and encourage Sam to make self-assessments. So you don't need to do the assessment, Sam makes the assessment. What you provide is framing. You're going to tell them context and ideas that they don't know about yet. Don't tell them what to think. This is kind of a delicate line, but figure out what questions they can ask. So let's pause here for a second, because this is the most often asked question that I get talking about different kinds of mentoring and code reviews and things. The first thing that happens when you start mentoring is they're showing somebody, you're showing somebody code, and they look at you and nod. Somebody has a mentor here, uh-oh, he says, can you interpret what that means? I don't know what it means when you nod, but I do it a lot when other people are helping me through code I don't know yet. It means I'm paying attention. It doesn't mean I understand yet. It doesn't mean I won't if you keep going the way you are, but it doesn't mean I will either. So people start asking questions. Do you know what this means? Is this going to return a string or a symbol? That's better than not asking any question, but it's not really asking the right kind of question. If it can be answered with a yes or a no, you didn't learn anything about them by asking that question. Try to ask something more vague, especially when you don't know where they are at all. How do you know about string parameters instead of do you know how string parameters works? If you ask something general like that, you're going to get a much more nuanced conversation, and you can kind of lead them towards what you think they need to know, and you'll be able to find out right away like how to direct your efforts, what kind of level of detail are they already aware of. So you don't waste your time on stuff they already know, and it's boring to them, but you don't talk over their head if, you know, oh, I just worked on them. I don't know that's yet. So avoid yes and no questions. So basically, it's trying to empower Sam. Sam is not ready for Valorog yet, but they can hold that orc inventory off for you while you fight the demon, and then Sam will eventually grow into this awesome dev who can fight demons, too. Dream big, and you're going to improve Sam's chances of success. So there's four main activities we're going to talk about, like how you're going to steer the ship, setting big goals, like figuring out, identifying what it is you want to accomplish is the first step, and then making sure that you've devoted adequate time and resources so that it's achievable, and then we're going to cycle back and forth between this little circle of, you know, assessing what they've done, what you want to do, reprioritizing what you want to do, and acknowledging when you've succeeded, and then once in a while cycle back. So step one, we're going to set some goals. Identifying what it is we want to do. Sit down with someone, the person who wants to learn, who's asked you for help, say, what is it that you want help with? You know, if they just say, I want a job, that's maybe not super helpful. But you can always suggest one. Well, I know Ruby, you could get a job in Ruby. You want to be an awesome Ruby dev. I think that'd be awesome. But try and get Sam to suggest some ideas. What do you think it means to be awesome at Ruby? What are some adjacent skills that you're going to need? You know, you can't just do Ruby all day. It'd be great. But, you know, you need other things too. Maybe you need a little bash. Try to get Sam to write a lot of things. Figure out, like, oh, I want to be full stack. I hear that one a lot. I want to do the full stack. You don't know what you're asking for, but okay, yeah, it sounds like fun. And then Sam can keep asking stuff. You want to learn how to write tests. That's great. Get fast with your editors. Oh my gosh. Oh my gosh, there's so many things we could do. It's so great. Oh my God. It's out of control. This is actually my list. No, it is actually. But that's a great sign. It's a great sign. You've got a curious, a bright mind. I want to do, all those things sound awesome to me too. Just, you've let the constraints go. You're free. You could learn anything. You know, don't fall for the ambiguity effect. Are you guys familiar with the ambiguity effect? Raise your hand if you know the ambiguity effect. The ambiguity effect is one of those like strawman argument, a ton of falsities where it's like, I don't know what I don't know yet. And so it must not be that much. And it's not that important. And I probably couldn't do it anyway. It's kind of like a self the facing sort of, I should have made a slide about that too. It's basically like limiting your horizons based on where you are now. So just break free of that. You could do anything. And we're just organizing it right now. So let's organize it. Let's set it up. Okay. All right, as much as I want to know how to speak Japanese and go talk to my hats. I did have dinner with them, but I don't know Japanese yet. It's not really important if you're working on a Ruby job. So organize your time by the things that are distractions right now. That's not saying you'll never learn them. It's just like, I'm not actually gonna work on that right now. Organize them by the things I'm gonna work on. And those two are in a category that's important and it's gonna take a lot of time. And that's the first category there the most time. And then, you know, okay. I'm gonna read some special stuff about paracrogramming, simple log articles or whatever. But it's not gonna take as long to learn how to do that. And I'm gonna practice that sort of implicitly anyway. So I don't need to explicitly practice like read as much on that as I do different design patterns. So these things will take less time. These things will take more time. And we're gonna organize the learning plan around these topics. So that way, the topics that you're learning on are the topics that you need. So you don't waste any time on topics that somebody else says are important, but they aren't applicable to your situation. So here's the hard part, breaking it down. For this style of like the apprenticeship program we do, you're gonna spend some time pairing with them and code reviewing I'm sure anyway. And to do this plan, like you need probably an hour every week, like just a meeting together where you can have a conversation. Especially at first, you're gonna take probably, I don't know, I just guessed out here, half a day to assess new resources that will go down the more people that you talk to because you already assessed some of those resources. Sam's gonna have to put the bulk of the work in, right, the one learning. And you know, laptop subscriptions, maybe you need to order some books, that kind of stuff. And you know, you're maybe gonna have a little reduced, like some opportunity cost and reduced capacity from you as a dev while you're pairing with Sam and doing stuff that's like a little bit easier that Sam's gonna be able to understand at first. And then where are you gonna organize our plan in? I don't actually really care. People talk about this like, of the people I've talked about this, this is probably like the biggest like, oh, what could I use? We could have fun with this. I could make my own thing. Ah, it doesn't matter. The little cards are cool. But as long as you can go both get in there, add things and check them off. Don't make it too perfect until you've done like at least two or three people. And then, you know, you can start breaking it down. I just change stuff so much between people that I don't even use anything fancy. So, all right. Thinking more of big thoughts about the plan. So the plan is actually Sam's. So you're gonna need to release ownership of the plan. That's hard, cause you wanna make choices about the plan. But what we wanna do is guide Sam to make the right choices instead of making choices ourselves. So the plan belongs to Sam. Even if Sam's gonna make some wrong steps, let them do it. Maybe not like a big wrong step, but some smaller wrong steps. You know, protect them from the big wrong steps. Do lots of little steps. And then that way, if they make a wrong step, they can see that error themselves and correct it. You wanna make it a list of to-do items. And every one of them should apply like the topic of every one of them. You're gonna learn something that was one of those topics in the previous slide. So as you assess resources, pick ones that are exactly what you wanna learn. Make sure that they're not too long. You don't want anything, especially the beginning that takes more than a couple of hours to complete. If it's gonna take like a big book, you're gonna read Sandy Metz's photo book. That's a great goal for the end, but the first couple of weeks don't do it. It's too easy to get lost. And another big point is your capacity to learn varies a lot by method of transmission. So you've just worked nine hours today on your laptop. That blog post is great for that screencast is great, but your eyes are gonna be fatigued. Sam's eyes are gonna be fatigued. The paper book might be a better choice. Just maybe pick one chapter at a time, instead of the whole thing. But print it out, even. Print out your blog article. Sorry, trees, it'll be great. Sorry, trees, but it'll be great for your learning. So assessing learning tools. And that's what I'm talking about, is like just collecting screencasts and blog articles and that kind of thing. Podcasts that you listen to, books that you've read, things on online places like edX or Coursera. Assess them for quality effectiveness and speed of use. So the main thing to think about when you're assessing things is not to just be like, oh, this is about SQL. They need to know some SQL, here you go. You should read it first and then think, okay, what will Sam be able to do after learning the concepts that this presents? Will they be able to learn those concepts the way that it's been presented here? What exactly topic does it cover? Okay, it's on SQL, you need to know some SQL. Okay, is it accurate? How dated is it? That's a big deal for us, right? How thorough is it? Who is the author? What was the person's motivation to create this resource? It's great if you just wanna share, and that's what we'd like to do is just share our knowledge, right? But maybe somebody's just a little skewed one way or the other, for some other reason. Compare the difficulty of the material to Sam's current output. And here's a good one. So I'm just talking, right? And I'll do this at the end. Does it link other resources? Some do and some really don't at all. If it leads you on a journey like that, it shows that it's a lot more, it's showing you what you can learn next, and it's more legitimate, like you can prove that the things that they've said are true, or here's an argument for, here's an argument against. Here's some evidence that would lead us to believe that. And then the format thing. Is it on paper? Is it a print? How long is it gonna take Sam to complete? And is it interesting? Is it gonna engage them so that they stick with it and learn? It makes it easier for you to stick with it and learn. So we'll sit together and come up with a list. You should probably come up with the list the first week. And I just threw together one that was full of some stuff that I've done for a few other people to use for this talk. And I just didn't cheat because it's really easy for me to give you a link there. So get a list of things that you would wanna know the topics that they're about. Pick a few. Like here's one about Ruby, here's one about learning. Here's some Rails and webs and Unix. Okay, great. And then put those together and make sure it's a little bit more than they're gonna be able to get done that week. Give them a little bit of a stretch room. So it's not like, okay, it's a deadline, here's where you get done. You're gonna work through a little bit every day and see how far you can get. Grab one from each topic and then mix in some things you need urgently. You may not be able to do that as much at the beginning, but as you go down, hey, I need this CSV import. Okay, here's a blog article about how that library works. But make it so that it's easy to just grab one, click the link, read it and do it. A checklist, really. And they'll learn the concepts inside of it. So that's the first big steps towards empowering Sam. Sam is ready to go. Sam is gonna get this done. The next thing to consider, though, is that we're managing them at work, too, right? That's gonna affect Sam's outcome a lot, so let's talk about it. When you're selecting what stories Sam is gonna do, what ones you're gonna pair together on, you know, I usually was selecting the work, the learning around the stories I knew were coming, but sometimes you can do the other way around. You can select the work around what they've learned. So go for it. Try and pair program with them as much as you can. That's probably the most important thing, although that turns out to be a really difficult thing to measure. I try to get some stuff on that at work, and it's just tough to measure because everyone defines it slightly differently. But if you can get time with you pairing it with them, especially if you can get other people that are of varied experience level to pair with the apprentice or the junior person you've just started, it takes a village. If you can get a more experience of wider range, they can see how each person deals with things slightly differently and learn from that. And of course, I'm all about trial by fire. Go for what really matters. If it doesn't, if it matters, why aren't you going for it? Try and get some code live their first day if you can. I mean, at least the first week, get something live so they can point and be like, that was me, I did it, I can do this. And build that trust with Sam and with your coworkers that, you know, I'm gonna let you take some small missteps, but I'm gonna guide you away from the big cliff edge. So your coworkers know they're gonna take care of Sam and Sam knows you're gonna help take care of them. One other thing, try and keep their work exciting. Don't give them intern work, it's boring. And code reviews, there's so many resources online, I'm not gonna talk too much about that. But I think it's a great feedback mechanism to measure their success in learning. When I was teaching, that was always the thing, right? Nobody wants to take a quiz, nobody wants to take a test, it stresses them out. You don't have to do that, they wrote code, there's an artifact right there, right? You don't have to make them make a test, it's great. It's already there. Sandwich the criticism between complaints, like tell them what they're doing well, as well as telling them what they're not doing well. Ask the questions and then see if you can get them to explain to you how they might fix it. Maybe you can choose between two or three different paths. That's a great way to teach them stuff. But if they really don't know what's going on, give them a bunch of exemplars. Show them examples of somebody else's code, even on some other project, and provide some context. I think they chose this code here because they were under a time limit. It works, but if I had time, I would do it this way. Here's another example. So they can understand when a decision is gonna be called bad by someone, and when it's gonna be called the same decision might otherwise be called good. There's some more resources about this in the downloadable plan that I've included at the end. So they hop on and check off things as they complete them. You go hunt for more resources and add them to the bottom of the list. And then they start adding stuff too, maybe they've found. And then once a week, have a check-in, your check-in meeting, and discuss how everything's going. They can brain dump on you. This is what I thought about this article. I didn't understand this thing about whatever here, the joins, what happens. And then maybe you can adjust your resource collection based on that feedback. So you make that as immediate as possible. Okay, so maybe at the beginning you're feeling a little overwhelmed. I don't know how well you can see Sam in that picture. He's looking overwhelmed. So let's talk about how to prioritize your work. There's so much to learn. You may have heard this, President Eisenhower said, I have two kinds of problems, the urgent and the important. The urgent are not important and the important are never urgent. So this was popularized by the book Seven Habits, those highly effective people. If you imagine urgency on the x-axis and importance on the y, you can see, okay, maybe we need that CSB important by Tuesday, but CSB imports aren't that important for them to learn. It's really important that they learn about dependency management or something. So that's kind of a good way to throw out things that you don't need, scope it down a little bit. And then once you've combined those into the things that are important and urgent, and the things that are important in your priority level, then you can also add that axis of cost and say, okay, this is really important. It's really urgent and it's cheap, just do it. And then the big high cost items, you're gonna wanna split across multiple weeks so that you hit it a little bit every time and that's gonna add up over the time. So keep doing that every week. They keep learning, you keep checking in with them. And then every month or so, every four weeks, I would say, do a check in on your larger goals and reassess. Are we working towards Rails and Ruby? Or did they end up doing a lot of server scripting? Is what we end up doing actually what we thought we needed at the beginning? Maybe we steered off and maybe that is actually where we should have steered to begin with or maybe we just need to straighten back out. So in the middle can be a little depressing or working towards a big goal and it's hard. Maybe that's a little overwhelming, the dragon's coming. You can see him, he's here. Let's try and stay positive. Here I have a nice little chart there. At first, you knew you were gonna lose some capacity to training and it can kind of feel impossible. But you're at the big point of the trilogy. Things go up from here. By the end, you can see you're doing so much more than you were at the beginning. See, my completely made up chart. Actually, okay, it's not really completely made up. This is actually, story points of my capacity was floating around 20 and then we brought on Dave. And then Dave got super independent and here we're way above where I was by myself already. So, but at the big, you know, I was right here and so it's hard to feel positive right when you're down here. But this part is coming. It kind of looks like the big dipper. It happens to the apprentices too, right? I mean, I did that part too, but it's been a little longer ago. So, at LaunchCode where we do surveys of people who are going through the apprenticeship program because they're working at different companies so we don't communicate, it's like it's hard to stay communicating with them. So we send them stuff. Find out how they're doing. Mostly so that we can intervene if somebody's in trouble but we're also getting this general rating and I always wondered what was going on with that. So we did this little study of it. This data has been normalized. This is actually the response data from people. It's normalized over the length of their apprenticeship. So if it took six weeks or if it took 20, that's 100% of the length of time. And the ratings are also normalized. So it's, we moved people who only answered once and things like that. Or if you answered like exactly the same every time we took that out. And what it shows really is that they actually feel really like it's going up the whole time as they start to realize how well they could do. That's really great. And oh and this is also only successful apprentices. That's like 90 something percent. So that's pretty much almost all of them anyway. So it's trending up. They're getting happier with a little range of doubt because our numbers aren't like super high on responses. Who wants to fill out surveys, right? But you have these outliers. Do you see these little guys down here at the bottom? That person made it. But they felt so bad. Whoops. Down here, sorry guys. This person here felt bad. And these people here, they felt bad. Oh my gosh. But they made it. So they just didn't know what they didn't know and they didn't know, you know, there was like that moment of doubt and that imposter syndrome happening sometime in the middle. It could happen anytime. But it can be overcome. So how can you overcome that? Here we are. We're software developers but we're managing people's motivation. That's what you have to do to communicate, right? So there's still a lot of confusion about this but I'll go over it really fast. Reinforcement attempts to increase behaviors you want. Punishment, you're attempting to reduce and eliminate behaviors you don't want. And both of these can be negative or positive. And negative is removing a thing. So like negative reinforcement, a lot of people who when they first get this kind of a job are like really happy. The negative reinforcement happens naturally. They had an income struggle that you removed. Now they have room for hope. But you want to try and do, we want to try and do positive reinforcement because that's the strongest motivator, right? But how can you apply this to software? I think it's still shaping even if it's whatever you're in. It can be as simple as that compliment you gave them on the code review. Don't just point out the flaws in the code review. Anytime they're working, I found this article on ActiveRecord and you need to use that. And then you should recognize work in that direction. Or point it out in front of other person. Morning stand up, tell them, oh Sam already finished that whole book. Can you believe that? That's awesome. Sometimes this is called successive approximation. It works on yourself. Use it. It works on your pets. Use it. It works on your spouse. I mean nothing, sorry honey. But the point that you need to come across to use this correctly so you don't like just end up being happy all the time, right? Wait, no. The point so that it actually changes behavior is that once you've done the same correct thing that's closer to correct but it's not exactly correct, you start reducing one of these dimensions of strength. They don't get rewarded every single time. Maybe like, oh that's a great thing. Instead of talking about it for 10 minutes. Latency, I don't have to explain that to you guys. If you just wait to respond, that reduces the strength of that response and so then they're gonna have to go a little, they're gonna try a little harder, get it a little more accurate to achieve that same level of response again and then that's how you can lead the behavior in the direction you want it to go. So Sam is starting to feel confident. Sam has been working, Sam is getting there. Week eight, time for another big point to check in. How's it going? You can start to introduce some more complicated things in larger books and you should subscribe to this podcast instead of just check off items. Read this one blog article. If you're doing the contract to a higher type situation you should talk about it but even if you're not, this is like a project. So see if we're gonna make our 90 day goal. If you don't think we are, see if you can scope it down a little bit. Maybe we wanted to be full stack but that's kind of a lot of stuff. Maybe you could just do one side for the first 90 days and then learn the other one. What if we added a couple of weeks or maybe four weeks? Could we make it then? I mean if it's just a week or two, add it. But if they are, make sure you tell them they are. Keep working hard, you can push through this, let's go. Same thing to do anything, same thing to do anything. By week 12 it should be just a couple of things left. What absolutely must be finished if it doesn't absolutely have to be finished, get it off there. There's still gonna be a junior developer when they're done with this but they're gonna be so much, like need less direct support and have gotten so much knowledge out of this. See if there's some kind of symbol of success that you can directly tie to completion. So with the apprenticeship things most people will convert then and get a title, they switch to salary, things are great. If it's a private type thing, a situation like you're just helping someone on the side, come up with some kind of symbol of success and then that gives that moment at the end. You reach the end of the video game and it gave you this vast screen, it seems like an easy and small thing but it matters so much and celebrate, celebrate. Enjoy, tell other people how Sam succeeded. Tell them how Sam succeeded. Maybe you're a humble brag at a level, Sam succeeded. Oh yeah, I did. I did too. And when you're done, take some time off before your next thing. Both of you, give yourself some introvert time, introvert for awhile. It's not sustainable to do this level of work long term. Sam probably used up some asks from family and friends just to maintain this level of work but most people cycle back in as their lives allow to allow further progress in their careers and they want to help other people too. And it's so rewarding to see that kind of compounding, like pay it forward stuff that, you know, I helped this person and they helped these three people and now there's like 20 people who are all like, grandbabies basically. By the way, I did not make this shit up. That's a lot of stuff to have made up. Though honestly, like most of this is based on my own experiences and it's basically what I did to my flu students just on software and what Mike Mene did to me at Launch Code. Thanks, Mike. Here's some springboards where you can go learn more about these things. And of course there's always the Google search to just find everything else that you might wanna know but then you don't have that, you know, assessment that has already been checked out by me. One other thing I touched upon, we talked about a little bit about learning strategies, being flexible to allow theirs. It's not the focus of this talk so I don't really wanna take questions on these but I'd be really happy to discuss them later. Typically what I mean by that is things that they address like specific behaviors you can do to address one type of issue. So it applies probably to some group of people like 10 or 20% of people but it's not relevant to other people. That's what I mean when I say like learning strategies. For example, if you have trouble like staying focused or you can't break focus, people will set a timer. Oh, I can set a 25 minute timer and I can keep myself focused and no one to break. That's really helpful but for people who don't have a problem with that, it's kind of like a waste of time so I didn't really want, and there's so many of those things. We've been here for a long time. So tweet them to me, let me know. Send me to Cheryl G. Schaefer there. Rather than taking question time on those, let me know what your favorite one is, what you've done with other people and we can just like help each other, I'll learn. So I hope everybody caught my main thesis here is that building the plan is really more important than what the contents of the plan is. So process over content. You can change the content and tweak it to what you need if you have a good process already done. So that's it for this one. Does anybody have any questions? Okay, the question was can I talk about specific things that have gone wrong in pair programming and how to avoid them? I think probably the thing that goes wrong for me pairing the most, well, there's two things. The first one is chatting. I like to talk. I find a lot of topics interesting and really a web form is not one of those things that I find interesting.