Quit Frustrating Your New Developers - Tips From a Teacher
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Rezentes, Miki
Your team gains a new developer. You are responsible for bringing them up to speed. While not everyone is a natural teacher, everyone can be taught basic teaching fundamentals. We will take a look at principles anyone can use to become a more effective trainer/teacher. Better teaching technique makes the training process more effective and enjoyable. Effective training reduces new developer frustration and increases job satisfaction for everyone.
 Good afternoon. My name is Mickey Risenes. Can everyone hear me okay? Awesome. So welcome to the talk. I work for Spreedly in Durham, North Carolina. I'm a software engineer and my Twitter handle is Mickey Rez. Feel free to reach out. At Spreedly, I develop on Active Merchant and also other Spreedly things. I also wrote a library for Android Pay, Decryption of Tokens. So I have some software credibility, I guess is what I'm trying to say. I don't know. It's always up for grabs. All right. So a little background on myself. I married young and had five children and I homeschooled them for 16 years. And from the time that I was 18, I've been tutoring or teaching math for money, which is always great. I've coached roughly 15 high school sports teams, two of which have won state championships. And all this is just to say that I'm used to being on top and the one in charge and the one with answers. And it's a really nice, fun place to be. Roughly six years ago, I returned to school to finish my degree because I was going to return to work and my husband was going to come home and say with kids. And that marked the beginning of my journey back up the totem pole. Being at the bottom again, it's very enlightening to put yourself on the bottom of that totem pole. So I would like to quick rabbit trail. I suggest anyone that's in a position of teaching, take the opportunity sometime to put yourself in a position of the learner, if only so you can realize all the things you don't want to be as a teacher. Also in this industry specifically, there's a lot of you have to come through your fears a lot because there's so many times you have to say you don't know this or you don't know that and that can be afraid. You can be afraid to admit that. So I recommend something with a little fear factor in it. Not necessarily derby, but it was fun. So when I first started putting this talk together, I realized that I wanted to make it for basically any new dev that came to your company. And I did, except I realized as I was going through it that I really projected some of my preferences on any new dev. And I don't think you're going to get away from that, but what I can do is tell you what my preferences are so that if you see that heavy thread, you know that I already have that preference. One of my preferences is that I have to have regular feedback, clear evaluation criteria and defined expectations. If I don't have those, I'm unhappy. I get unhappy a lot just so you know you're going to see this. All right. If I'm not growing, I'm unhappy. Again. I love teens. So when I feel isolated, I'm unhappy. And I believe that training is a two person activity. So if you're in a position to train someone and that person is not willing to put in the work to learn, then you've hired the wrong person and this talk is not for you. You should go find a hiring talk to figure out how not to hire those people. So there are three basic teaching opportunities that you're going to run into when you onboard someone or sorry, when you hire a new dev. The first teaching opportunity will be onboarding. This will be about six to eight weeks depending. And the next type of opportunity will be continuing education, training or mentoring. And this will be unbounded in time. This should be as an engineer, this should be your whole career. You should be learning and preferably you should have someone to help you along the path even if it's just up here once you reach the senior level. And then you're going to have routine daily questions. I'm going to break down types of knowledge into three categories as well. First, there's tools of trade type knowledge. This will be your languages, design, data structures, databases, all those type of things that you would learn from a wiki or a book or more book academic type learning. So we're going to call those tools of the trade. Also you will be having to teach domain or industry specific knowledge. For example, I work at Screeley. We run credit cards. We help people process them. So I have to know a lot about PCI compliance. It has nothing to do with computers, but if I don't know what, I can't write the program. And then there will be company policies and development process. So basically just company information. These are the three types of information that you need to know how to deal with. And there are two types of new developers. I'm going through all these types. Who doesn't like text on any? You have experienced developers new to your team. And so they clearly have different needs than junior developers new to all the things. So the teaching should be the same, a lot of the same principles, but juniors will need more help in the tools of the trade area. And now an overview of what teach... Am I going to go there again? Overview. If I'm talking and it seems like I should go another slide, just flag me down. I'm really cool with that. Overview of teaching and training. So I'm going to give you everything you need to know about what the point is. The point of teaching and training is to reduce unknowns. And if training isn't reducing unknowns, what's the point? You're doing something wrong. So throughout this talk, and as you go back to where you are, you always have to ask yourself when you're training, am I reducing unknowns? Because people will make it about all kinds of other things, but really it's about conquering the unknown. For example, I'm onboarding someone at Spreely right now. And first week, you'll just be talking with them. And you'll say, and I say, and then my lead, Ryan says, how are you doing? And he's like, I don't know what you guys want me to tell you when you say how you're doing. My stomach's upset, I had a great breakfast. No. What we're looking for... So then I had to really quantify it. It forced me to quantify. He had an unknown. There was an expectation I had. I really didn't communicate what it was. I asked this general question. I'm like, okay, when I ask you how you're doing, I want to know three things. One, do you have something to work on? Two, are you blocked? Three, is there some question that I can answer for you? So that was a teaching opportunity because he had an unknown and I had to fix the unknown. And every time you have a new developer and you fix an unknown, they are more comfortable and they will become more productive. So most of us are familiar with this iceberg thing. Most of you probably know where I'm going with this. Totally projecting. So we have known unknowns, things that we know that we don't know. For example, there's a distance between Earth and Pluto. I don't know what that is. That's a known unknown. I can't give you one of my unknown unknowns because I don't even know that I don't know it. But I can't give you one of my daughter. I have an 11-year-old daughter. She doesn't even know that she doesn't know what a data structure is. So we have unknown unknowns and we have known unknowns. So basically the top is what we know we don't know. And you know what is going on. And the bottom represents all the things we don't even realize we don't know. But the problem here is that it's wrong. The bottom of the iceberg is woefully too small to represent how much we don't know. And what's going to happen is thank God, junior devs don't know this because I think they would all run if they understood how much they didn't know. So experience devs, what happens for experience, brings you encounter a problem, you solve the problem. Then you realize that you're able to solve this problem even though you had no idea how to solve it when you started. So that gives you confidence that even though you have no idea how you're going to get to finish line, I've gotten to finish line tons of times totally not knowing what I was doing. I can just do that again. But junior devs haven't experienced that success yet. And so you really need to get them to stick around long enough and expose the fact that you don't know what you're doing sometimes. It's really important for them to see. Get them to stick around long enough to see that really you start, a software engineering is about starting with all kinds of things that you don't know and whittling it down, answering those unknowns and having a solution. So when you go back and you're trying to assess how am I doing? Am I teaching better? Am I doing a good job training? You have to ask yourself two questions. The first question is, are you reducing unknowns? And it's shocking how many people can teach for a long period of time and never reduce a single unknown. And you can fall into this like if you're preaching to the choir, it doesn't help anyone. So make sure you're reducing unknowns. And the other thing is, are your devs acquiring more problem solving skills? Because the fact of the matter is, junior devs don't have as many problem solving skills. Experienced devs will have more. But whenever you change stacks or change companies, there's going to be new problem solving skills that you're going to have to learn for that stack or for that company. And so like for example, I want to spree lane, I'm setting up my machine and I can't get stuff to run. I said stuff, I was good. I can't get things to run on my machine. And so it's almost like it's post-gress running. Well, I thought it was. I thought it wasn't. So and the thing is, is that I'm not a junior dev, but I needed help in that area and that was helping me with a problem solving skill. Now on my very first team, I had a wonderful teammate and she helped me run a great problem solving skill. So she would send me helpful links. Now you might, and so like at first you're like, ha ha, and you're like, damn it. Why did I just ask that question? But she really helped me out because junior devs really do need to go to Google first. If you haven't asked Google, don't ask me. So that is a job skill and they should have that. So now we're going to go into the seven laws of teaching. I was a teacher as you saw in my bio and I like eating, which you probably already saw in my bio. It seems like my favorite thing to do besides skate. All right, so seven laws of teaching. They seem straightforward and people mess them up all the time. This is a book written in 1884 and all classically trained teachers should have read it. So I'm going to go through the laws and apply them to software. The law of the teacher, the teacher must know that which he would teach, therefore know thoroughly, clearly, and familiarly the lesson you wish to teach. Now because there are three types of teaching opportunities, I'm going to go through them individually for this lesson. First you have onboarding. And many people feel like onboarding is their personal, like it's a one man show, it's not, it should be a team or company show. If you don't know what you're supposed to be teaching during onboarding, you can't onboard someone. And you can't make that decision alone unless you're the manager or the owner. So basically there should be things that you're trying to teach people during onboarding, mostly involving company specific information of the three types of information you have that can be your science, the domain and the company. Company and domain are going to be big during the onboarding process. Once you finish the six to eight week, they should have an idea of what the company is about. They shouldn't be uncovering new company things as they roll through. But the important thing is that you can't figure this out on your own. You've got to have someone help you. If this is definitely a team issue. Now at Spreedly, my lead Ryan, if he has touched anything, there's document on it. And I love that. Also if you touch something, once you do document it, I hate that. So that was priceless coming in because there was always documentation on anything that I needed. And so after I came in, then shortly three more developers came on. And what we realized is that all of us, there was no onboarding process, but all of us did the same things for the first six weeks. And so we had a process. We just hadn't written it down. So what Ryan did was he went and he created a new engineer's handbook. And this has been invaluable. The new engineer's handbook covers all things from setting up your machine, what type of work assignments you're going to have, the expectations like office hours. Basically what you need to know to have all those things that people that have been in the company for six months to a year, if they've been there, they kind of know all these things. You want those things in your handbook. You want to answer as many unknowns about the company so you can get that off of their plate and start really coding and talking about domain. So some other things that you can do during the onboarding process will be you want to make sure they understand your dev process and the working agreements on your team. For example, do you have a definition of done done? They should know what that is and they should know what that is pretty quickly. Am I talking too fast? I'm just going with Arthur's response. I'm not listening to anyone else apparently. All right. Also present your style guide. You may not have one and I, it's okay, I'll get on you, but if you have a style guide, it's nice for them to know how you want them to write their code. And if you don't have one, I suggest you get one. If only for you, you want to adopt one basically so people coming on know the expectation, not so that you can hammer people over the head, although that's fun too, but you definitely want everyone to know the expectation. Now you want to know how the team fits in the company as a whole. That's an important thing for them to know with whatever team they're going to. Also to understand how the developer fits in the team. Basically all of this is trying to manage expectations. And then you want to tell them how the team deals with conflict before the conflict comes up. It's already stressful coming on in the company. And if you come on and there are, and you have conflicts right out of the gate, like that would ever happen, it would be nice to know what the process is before you face it. Then you have continuing education and mentoring. And the goal here, this is unbounded. So this will happen over weeks and months, hopefully years if they like the team. And the point of continuing education and mentoring is to take people where they are on your ladder, whatever level they are, have them master those skills and also push them towards the next level. Engineers want to grow. And so if they feel like you're helping them master their skill set and also pushing them to the next level of their skill set, it's reassuring that they're not the only ones driving their career. So you want to make sure that they know what the engineering ladder is. You want to go over that, what your expectations are for them to move on to the next level. Because everyone wants to move on. And if they don't want to move on, you should probably get rid of them. Because people that aren't getting better aren't worth it. I'm sorry, I'm very harsh like that. Style guide reviews are a great thing to do during this time because most style guides, like for example Airbnb has a JavaScript style guide that I spent a lot of time in at one point. And I enjoyed it because I like knowing why people are making those style decisions. Now people can be flipping about style and just not, you have to do this way. But a lot of times they have good reasons why they've made those decisions. And so going over that with inexperienced devs is a good way for them to make their own opinions. Because really what you're wanting them to do is acquire strong opinions and hold them loosely. What that means is they should have an opinion and be able to discuss other opinions and hopefully improve their opinion. And so this continuing education should be helping them along that path. And then lastly, you need a core book list and recommended reading list. So every company has things that they value. And if you don't, when I was homeschooling all my kids read the same set of core books. What this did for us is when we sat down at the table and we wanted to discuss something, we could reference the same books. We want to talk about government. They already read the Federalist Papers. They read the Anti-Federalist Papers. They read John Locke. They read Rousseau. We could hit any of those and all my kids will know what you're talking about. It's awesome when you can talk to your kids, when you can talk in a group and you all have the same reference points. So having a core book list can help get everyone on the same page. And that's very helpful for having better opinions, holding them strongly or holding them loosely and being able to defend those decisions. And then the last for the law of the lesson, the routine questions. So on these, you need to have the answer or know how to find the answer. Be able to teach them the process and how they're going to find that answer because you can't plan this out. And the same teaching goals apply. You need to be reducing unknowns and demonstrating problem-solving skills. So if in the course of a routine question, you realize they're missing something that they should already know, you should fill in that gap right then because every time you fill in an unknown, developers are more happy and they're more productive. The second law is allow the learner. The learner must attend with interest to the material to be learned. Therefore, gain and keep the attention and interest of the pupils on the lesson. Don't try to teach without attention. This comes down to hiring. You need to make sure you're hiring people that want to learn. But also, you need to provide an environment that is conducive to learning, which means you need to welcome questions. And the reason why you need to welcome questions is because questions expose unknowns. And you can't fix an unknown until someone's told you they have it. So you definitely want to foster that environment, which means that if asking questions is good, everyone should be doing it. It shouldn't just be the more inexperienced. You know, they should see seniors asking questions. It's encouraging to them to make sure they ask theirs. Now, if you have an experienced developer who's not asking questions, one of two things is going on there. One, they haven't reached their full potential. Or two, they are just really good at Google. The second one is acceptable. The first one is not. So another thing that we did at Spreeley is we made a Slack onboarding channel. And this allowed people to be able to go into a more private room with you have your mentors and just your onboarding people there. And they can ask the questions without having to expose all their unknowns to everyone in the company, which can be, you know, rough after a few weeks. So, but I've gone through, you know, imposter syndrome is very common in our industry. Any level can face it. And so I've gone through and I've actually scripted. I had some really great actors and actresses actually play this out for me. I scripted this great little talk you can have with all new devs about imposter syndrome. No one knows what they're doing. This is a very helpful conversation. Everyone should hear this. Which is all faking it until we figured out. I mean, and I realized that some of us know things, but there's so many things that we don't know. And I think that we really need to make sure people realize how much experienced devs don't know. The Google did this study to figure out what made teams effective and what they came up with. One of the things, I'm not going to go through all five, but one of the things was psychological safety. And basically that is defined, can we take risks on this team without feeling insecure or embarrassed? And questions can be considered a risk. So if you can't ask questions without feeling insecure or embarrassed, your climate is bad. You need to fix that. So I also have this theory. I think this is my theory someone might have said before. So I'm not crediting them because I don't know. The number of regular interactions someone has with a team should improve their psychological safety. And I'm going to give you two scenarios. First, a developer has 40 interactions with their team, and of those 40, they're all questions. And the second developer, they have 200 interactions. They ask more questions. They ask 60, but they've had 200 interactions. Now that first developer that only had 40 interactions, they're going to start becoming very self-conscious about asking questions. Because every time they ask a question, it's a reminder that all they ever do is ask questions. And that can get heavy when you're coming on someplace. You want to have something to offer. You want to have something of value. And your questions are just a drain on those around you. And some people won't feel that, but some people will. And you want to watch out for that. The person that has 200 interactions and 60 of them are questions. The questions are part of the flow, but they don't define the flow. And this is where team building comes in handy. You need to have some interaction. And it can be meals. Meals is great because everyone has to eat. And you want to make sure that your activity is inclusive. So drinking, I like it, but not everyone does. So you want to do things that everyone on your team will enjoy. Water cooler chats. It's nice to have a kitchen where you can kind of go out and hang out with people and chat with them. You need to have more interactions than just questions all the time for the new people at your company. A foosball ping pong. Where else am I right with that? Company events and parties. And then, you know, team building type events. So basically you want to provide some interaction for your new people at your company that don't involve them, have to ask questions about things they don't know constantly. Pro tip. Don't start explanations with clearly or obviously. It's a bad juju. Just don't do it. The law of the language. The language used in teaching must be common to the teacher and the learner. Therefore, use words understood in the same way by the pupils and yourself. So there are two keys to success for this. Don't use industry specific acronyms or domain specific acronyms that frustrates people. They don't know what you're talking about. And it's disheartening. And we do it a lot. And then you want to define your terms as you go. At Spreely, we developed a repo that had a glossary of terms in it. And that was really helpful. So we would point the new people to the glossary. We would try to make sure we're explaining acronyms as we go. But at the very least they had some recourse to go figure out what acronyms were when they got confused, when they saw things in docs, and they didn't know what it was. So you want to make sure that you're using the same language. And I'm going to get an example from when I was teaching math. Number 12 here. One day, this is like step graphs. That's basically what this chapter is on. And a student raised their hands. And it turns out that they had never been to a post office. So they couldn't understand the problem. The language of the problem was beyond them. They didn't know what was going on. And so in order to... It made me feel old, which was not nice. And I could have just explained what a post office was, but that would have, again, made me feel older. So I changed it into text messages where the first four or like, you know, 120 text messages are this much money and then additional money for every block of 15 text messages after that. At this point in time, phone plans weren't doing the whole unlimited text thing. So they understood the problem and they were able to solve it, but they really needed to understand what the problem was there. The law of the lesson. The truth to be taught must be learned through truth already known. Or begin with what is already well known to the people about the subject and proceed to the new material by single easy natural steps. So this just means you have to teach from the known to the unknown. And we do this all the time. If someone asks what a word means, we don't define the word they don't understand with more words they don't understand. We define that word with words they do understand. So when you're working with a new developer, you want to make sure that wherever you're starting your explanation, they actually know where you are in that pipeline. So if they're back here and you start here, your explanation is useless. You have to make sure that you back up to where they are and some of that is going to be you asking them questions. But I have an example of someone chaining things together to help them learn something new. And it's not the greatest, but it shows the chaining part. Michael Scott has an amazing mnemonic device by which he memorizes people's names in the crowd. I don't know if you guys are office fans or not. Right? Your head is bald, it is hairless, it is shiny, it is reflective, like a mirror. Your name is Mark. Yes, got it, it works. So what Michael Scott is attempting to do here is chain things together. He knows to learn something he doesn't know, which is a good idea. I wouldn't do that though. Okay, so the idea is that you want to teach from the known to the unknown. Random factoids don't stick. You have to make sure everything is cohesive. So when I was teaching math, when a student couldn't complete this problem, I would ask if they could complete this problem. More often than not, they couldn't. And you would think that by the time you got sophomores and juniors in high school that they would be able to do that bottom problem. But most of the time, if they had a problem with the top problem with algebra and fractions, they actually couldn't do regular fractions. And if I started the explanation just working on the algebra, they were gone. I had to make sure I backed up and went over fractions again, which seems silly, but it's just reality. So sometimes I think of teaching like throwing toilet paper at a wall, you know, and so you just throw a bunch of information at people and you see what sticks. And that's kind of, it is what it feels like sometimes, but the reality of the situation is that that kind of takes away that you can affect, you can change the effectiveness. And how you change the effectiveness is when you're throwing the information and it actually attaches to something already. If they already have information and you throw more information that attaches, then it will actually stick. If you don't, it's just all wasted words. And it's frustrating too, because what happens is if someone asks me a question and I explain it to them, and at first like let's say Arthur asked me a question and I start explaining out here. Now the first time I do this, he might say, wait, I don't understand how you're out there. Like, and he'll pull me back to where he knows, because, you know, he's communicating. But if I continually end up in front of him all the time, way out here with my explanation, he's going to start feeling the need to save face, because he's like, I never, I never, I don't know what they're talking about all the time. And so then you just going to get this, oh yeah, yeah, yeah. That's not good, okay. So you got to make sure that you're starting where they are, because if once people go into save face mode, then you've kind of lost the battle, because now they're just trying to make sure that you don't think that they're stupid. And then, you know, see past rule on that. You want to make sure you have an environment where they can ask questions, where they feel like they can learn and have some psychological safety. The law of the teaching process. Teaching is arousing and using the pupil's mind to grasp the desired thought or to master the desired art. Therefore, stimulate the pupil's own mind to action. Keep his thought as much as possible ahead of your own expression. Placing him in the attitude of the discoverer or anticipator. Most of us know this by like, Socratic method type things. And so, you're trying to make sure your students are making the lessons their own, not just don't tell them. So, I think the best value as teachers that you can provide to students or people that you're training isn't to provide answers, but to teach them the right questions to ask. Just like, if you became an excellent Googler, you're just more effective, because you know how to ask questions. That's basically what makes people good at Google. What question do I ask? So, but it can be time consuming to teach people how to ask questions. So, I want to go over first the benefits to just answering questions. Because there are a few. Just answering questions. It's easy. It's fast. And I think number three is the most important one. It makes us feel smart. And it's even better if we can make them not feel smart. You know? So, like, if you're just answering questions, you have to ask yourself. If you're playing this little passive aggressive thing, where answering questions and not really providing the backdrop for someone not to answer that question again, it's kind of passive aggressive and you need to knock it off, because it makes people not like working with you. And also provides job security. So, that's another big benefit here. So, just answer questions. These are the things you'll get from that short-term gratification, but long-term it's bad for the team. So, in education, we use a thing called question-answer flow, which is basically where I ask a question and you give me the same answer. And we do this over subject matter. And you end up memorizing things. And when someone asks a question, they'll automatically know the answer. So, it's like predictive text, but it actually works. You want to reuse the same words verbatim. It triggers the person to start hearing your words before they ask the question. And it's extremely effective for math education. So, here's some examples. I would ask my class, what does of mean in math? Now, I'm sure many of you probably already had this question, like, means multiply. And you definitely want people to have that, this is, what do you do here? And they know the answer. So, you're basically teaching them how to ask questions. When they read a problem and there's of in it, they're like, oh, of, I have to multiply. What's the first thing we try to do when we see an algebraic fraction? Factor and reduce. Now, this is a harder one. People don't like fractions and people don't like algebra, so put the two together and they just hate that. So, at least if you give them some way of dealing with that fraction, the first thing you want to do, try to factor, try to reduce. At least they have something in their toolbox to address that. So, when I joined my first team that had a working agreement for testing on a PR, I would put the PR out and I'd ask for a review. Someone say, you wrote test for that, right? Like, damn it. You know, nothing else. Put it out there. But that only happened a couple of times before. I'd be like, I'm going to push the button. You wrote test for that, didn't you? No, darn it. So, that question-answer flow, using the same type of flow to get someone on board is very helpful. So, new developers need to hear that flow, even experienced new developers need to hear the flow because the stack is different. So, you want to take them when you're working through a problem with them or you're working through any issue. What you want to do is talk out loud and tell them where you'd start looking. You know, like when you call customer support, is the machine plugged in? Yes, the machine is plugged in. You know, they're starting debugging from the beginning. But when you start working on a code problem, we already have all these questions that we're asking ourselves, but we're not telling people that we're asking ourselves and resolving the question. So, when you're teaching someone, you want to ask the question out loud and resolve it so that they can learn your question-answer flow and they may not adopt all of them. But when any questions that they adopt will help them tremendously in their debugging efforts and also to understand that you're basically asking your questions to get to your answer and they should mimic you on that. Alright. So, although repeating answers is really great and helps people memorize the answers and have that available, if they don't understand your answer, repetition won't help at all. So, you need to go back to make sure you're using words that they understand and that you're starting somewhere that they can actually follow you. And then those types of answers, when you repeat them, they actually do help. The law of the learning process. The student must reproduce in his own mind the truth to be learned. Therefore, require the people to reproduce the thought the lesson he is learning. Thinking it out in various phases and applications until he can express it in his own language. I think the takeaway here is that we definitely want people to make this information their own and we want to give them a chance to apply it. And we also have to accept the fact that people have different learning styles. So, you have social learners and you have solitary learners. And although a company might have a certain culture of mostly pairing or mostly working alone, you want to make some accommodation for people, especially in the ramping up on-boarding period to do things that make them comfortable. Because having to learn a bunch of stuff and being comfortable is very difficult. If you have to learn a bunch of stuff, but you can be somewhat comfortable, it's just so much easier. So, if you have people that like pairing, accommodating them a little bit on the pairing, if you're not a pairing shop, it would be good. And also, if you have solitary learners, but you're a pairing shop, you might want to give them some time on their own just so that they can feel comfortable learning the stuff and feeling comfortable in that situation. You can't talk understanding into people. And this is something that I saw when I was, three years ago I started skating so I could play derby. And basically you would go to practice and someone would volunteer to teach. And the best teachers were the teachers that taught you your lesson and then they let you work on it. And it was a mess. I mean, you know, you're all over the place. But the fact of the matter is it's a physical activity and no matter how much you understand the physics, no matter how much someone tells you how you're supposed to plow stop or how you're supposed to hit someone, you just have to hit them a lot to get that down. So, the idea is that you can only tell someone so much and then you've got to give them time to work it out and you can't talk it into them. And people make the mistake of, I'm going to give them the benefit of the doubt that they're trying to help because the flip side of that coin is that they just like to hear themselves talk. So, if you find yourself talking a lot and someone's glazed over, ask yourself, am I helping them or I'd just like to hear myself talk because you're going to have to adjust that. The law review and application. The completion test in confirmation of the work of teaching must be made by review and application. Therefore, review, review, review, reproducing the old deepening its oppression with new thought, linking it with added meaning, finding new applications, correcting any false views and completing the true. I realize all these laws are like 1880s English. So, I apologize. But the idea here is that you want to review with people. I think PRs are probably one of the best ways to review to go over the work to make sure that they're doing things according to style, guidelines or maybe just design, things that how you want them to design. But in order for review and feedback to be helpful and effective, the developer needs to understand the expectations and the evaluation standard. So, if you have not made these things clear, you need to because it's just going to, it's going to really, this is probably the number one frustrating thing for me is if I'm not sure what you want from me, because I really want to do a good job. I don't want to just do a good job. I want to blow it out of water. But if you don't tell me what that looks like, like what is it if I just, you know, if I meet the bar, where is that? If you don't tell me where I can meet the bar, then I can't, I definitely can't jump over the bar. And that's really what I want to do. And the five keys to a successful Google team, one of the keys was structure and clarity. So, our goals and execution, goals, roles and execution plans on the team clear, because if they're not, you should fix that. Your team will be more effective. And then you need to establish a feedback cycle. Make sure that that new developer has a way to talk to, a comfortable way to, for you to check in on them. And the feedback there should go both ways. You should be able to give them feedback about how they're doing. They should give you feedback about how you're doing. I coached a volleyball team from middle school through high school. And at the end of six years, we won the state championship. And it was one of the things when I look at other teams we played over those years, because we're just a bunch of homeschool girls. Some of them literally couldn't run when I first got them. So, like, to take them from that to this championship team was, it was an amazing journey. And I watched a lot of other coaches with much better players, taller players, you know, club players. And we would just knock the snot out of them. We just beat them up. We made them cry. It was awesome. I mean, like, seriously, that is like the golden standard of coaching. Like, can you make the other team cry? I'm serious. So, I would watch these other coaches and I realized that really it wasn't a failure of the players. The players on those teams were fine. The coaches really didn't know how to use them. And the reason why is because the offense, because there is offense to volleyball, the offense that they run in Iran or the defense, there was some breakdown. The kids did not have the vision of the coach. And so, for six years, literally six years, I had the same exact huddle talk, so much so that if you're on my team for more than two months and I do this, you know the huddle talk's coming and you know exactly what I'm going to say. I'm going to tell you the three things you have to do to win a volleyball game. And then when we're in practice, I'm serious. And so, when we're in practice, we'll be serving. And I'm like, you go back there and you serve 10 serves and you better get four in because if you don't get four in, you know, like one, two, three, four, don't go in, you're letting your team down. I'm very clear about my expectations on that team because that is just the nature. If you want to win, this is what you have to do. So, my standards are really clear. I'm very good about giving them evaluation criteria. They can take that criteria and when I'm not there and the ball doesn't go to target when they pass and they shake it off somewhere, they know in their head, they already hear me yelling at them. So, they have that criteria and I'm telling you right now, those girls delivered. I mean, we whooped up big time. It's awesome. All right. So, the feedback cycle, I just covered that. High performers love to smash expectations. So, you're going to have like A developers, B developers, C developers. If you want your A developers to really take off, you better tell them what your expectations are because they're going to be aiming above those and they can't aim above what they don't know. And lastly, not only does being a good teacher help people learn, but it will help you learn too because when I'm talking with someone now as a teacher, if someone says a word that I don't know, I'm just like, I don't know that word. You have to explain it to me because I realize this is a breakdown in the teaching process. This isn't a Mickey's ignorance. I mean, I am, but that's not the point. The point is that they're trying to teach me something. They're trying to communicate something and I can't follow them because I don't know the words they're using or I need to say, you need to back up because I don't understand. And as a, once you understand how the teaching process works and the learning process works, you'll stop people and you will be able to be a better learner. Any questions? I know that I'm done and anyone can leave, but I don't want to not answer questions people have. We're good? Awesome. Thank you. You've been great. Thank you.
 Good afternoon. My name is Mickey Risenes. Can everyone hear me okay? Awesome. So welcome  to the talk. I work for Spreedly in Durham, North Carolina. I'm a software engineer and  my Twitter handle is Mickey Rez. Feel free to reach out. At Spreedly, I develop on Active  Merchant and also other Spreedly things. I also wrote a library for Android Pay, Decryption  of Tokens. So I have some software credibility, I guess is what I'm trying to say. I don't  know. It's always up for grabs. All right. So a little background on myself. I married  young and had five children and I homeschooled them for 16 years. And from the time that  I was 18, I've been tutoring or teaching math for money, which is always great. I've coached  roughly 15 high school sports teams, two of which have won state championships. And all  this is just to say that I'm used to being on top and the one in charge and the one with  answers. And it's a really nice, fun place to be. Roughly six years ago, I returned to  school to finish my degree because I was going to return to work and my husband was going  to come home and say with kids. And that marked the beginning of my journey back up the totem  pole. Being at the bottom again, it's very enlightening to put yourself on the bottom  of that totem pole. So I would like to quick rabbit trail. I suggest anyone that's in a  position of teaching, take the opportunity sometime to put yourself in a position of  the learner, if only so you can realize all the things you don't want to be as a teacher.  Also in this industry specifically, there's a lot of you have to come through your fears  a lot because there's so many times you have to say you don't know this or you don't know  that and that can be afraid. You can be afraid to admit that. So I recommend something with  a little fear factor in it. Not necessarily derby, but it was fun. So when I first started  putting this talk together, I realized that I wanted to make it for basically any new  dev that came to your company. And I did, except I realized as I was going through it  that I really projected some of my preferences on any new dev. And I don't think you're going  to get away from that, but what I can do is tell you what my preferences are so that  if you see that heavy thread, you know that I already have that preference. One of my  preferences is that I have to have regular feedback, clear evaluation criteria and defined  expectations. If I don't have those, I'm unhappy. I get unhappy a lot just so you know you're  going to see this. All right. If I'm not growing, I'm unhappy. Again. I love teens. So when  I feel isolated, I'm unhappy. And I believe that training is a two person activity. So  if you're in a position to train someone and that person is not willing to put in the work  to learn, then you've hired the wrong person and this talk is not for you. You should go  find a hiring talk to figure out how not to hire those people. So there are three basic  teaching opportunities that you're going to run into when you onboard someone or sorry,  when you hire a new dev. The first teaching opportunity will be onboarding. This will  be about six to eight weeks depending. And the next type of opportunity will be continuing  education, training or mentoring. And this will be unbounded in time. This should be  as an engineer, this should be your whole career. You should be learning and preferably  you should have someone to help you along the path even if it's just up here once you  reach the senior level. And then you're going to have routine daily questions. I'm going  to break down types of knowledge into three categories as well. First, there's tools of  trade type knowledge. This will be your languages, design, data structures, databases, all those  type of things that you would learn from a wiki or a book or more book academic type  learning. So we're going to call those tools of the trade. Also you will be having to teach  domain or industry specific knowledge. For example, I work at Screeley. We run credit  cards. We help people process them. So I have to know a lot about PCI compliance. It has  nothing to do with computers, but if I don't know what, I can't write the program. And  then there will be company policies and development process. So basically just company information.  These are the three types of information that you need to know how to deal with. And there  are two types of new developers. I'm going through all these types. Who doesn't like  text on any? You have experienced developers new to your team. And so they clearly have  different needs than junior developers new to all the things. So the teaching should  be the same, a lot of the same principles, but juniors will need more help in the tools  of the trade area. And now an overview of what teach... Am I going to go there again?  Overview. If I'm talking and it seems like I should go another slide, just flag me down.  I'm really cool with that. Overview of teaching and training. So I'm going to give you everything  you need to know about what the point is. The point of teaching and training is to reduce  unknowns. And if training isn't reducing unknowns, what's the point? You're doing something  wrong. So throughout this talk, and as you go back to where you are, you always have  to ask yourself when you're training, am I reducing unknowns? Because people will make  it about all kinds of other things, but really it's about conquering the unknown. For example,  I'm onboarding someone at Spreely right now. And first week, you'll just be talking with  them. And you'll say, and I say, and then my lead, Ryan says, how are you doing? And  he's like, I don't know what you guys want me to tell you when you say how you're doing.  My stomach's upset, I had a great breakfast. No. What we're looking for... So then I had  to really quantify it. It forced me to quantify. He had an unknown. There was an expectation  I had. I really didn't communicate what it was. I asked this general question. I'm like,  okay, when I ask you how you're doing, I want to know three things. One, do you have something  to work on? Two, are you blocked? Three, is there some question that I can answer for  you? So that was a teaching opportunity because he had an unknown and I had to fix the unknown.  And every time you have a new developer and you fix an unknown, they are more comfortable  and they will become more productive. So most of us are familiar with this iceberg thing.  Most of you probably know where I'm going with this. Totally projecting. So we have  known unknowns, things that we know that we don't know. For example, there's a distance  between Earth and Pluto. I don't know what that is. That's a known unknown. I can't give  you one of my unknown unknowns because I don't even know that I don't know it. But I can't  give you one of my daughter. I have an 11-year-old daughter. She doesn't even know that she doesn't  know what a data structure is. So we have unknown unknowns and we have known unknowns.  So basically the top is what we know we don't know. And you know what is going on. And the  bottom represents all the things we don't even realize we don't know. But the problem  here is that it's wrong. The bottom of the iceberg is woefully too small to represent  how much we don't know. And what's going to happen is thank God, junior devs don't know  this because I think they would all run if they understood how much they didn't know.  So experience devs, what happens for experience, brings you encounter a problem, you solve  the problem. Then you realize that you're able to solve this problem even though you  had no idea how to solve it when you started. So that gives you confidence that even though  you have no idea how you're going to get to finish line, I've gotten to finish line  tons of times totally not knowing what I was doing. I can just do that again. But junior  devs haven't experienced that success yet. And so you really need to get them to stick  around long enough and expose the fact that you don't know what you're doing sometimes.  It's really important for them to see. Get them to stick around long enough to see that  really you start, a software engineering is about starting with all kinds of things that  you don't know and whittling it down, answering those unknowns and having a solution. So when  you go back and you're trying to assess how am I doing? Am I teaching better? Am I doing  a good job training? You have to ask yourself two questions. The first question is, are  you reducing unknowns? And it's shocking how many people can teach for a long period  of time and never reduce a single unknown. And you can fall into this like if you're  preaching to the choir, it doesn't help anyone. So make sure you're reducing unknowns. And  the other thing is, are your devs acquiring more problem solving skills? Because the fact  of the matter is, junior devs don't have as many problem solving skills. Experienced devs  will have more. But whenever you change stacks or change companies, there's going to be new  problem solving skills that you're going to have to learn for that stack or for that  company. And so like for example, I want to spree lane, I'm setting up my machine and  I can't get stuff to run. I said stuff, I was good. I can't get things to run on my  machine. And so it's almost like it's post-gress running. Well, I thought it was. I thought  it wasn't. So and the thing is, is that I'm not a junior dev, but I needed help in that  area and that was helping me with a problem solving skill. Now on my very first team,  I had a wonderful teammate and she helped me run a great problem solving skill. So she  would send me helpful links. Now you might, and so like at first you're like, ha ha, and  you're like, damn it. Why did I just ask that question? But she really helped me out because  junior devs really do need to go to Google first. If you haven't asked Google, don't  ask me. So that is a job skill and they should have that. So now we're going to go into the  seven laws of teaching. I was a teacher as you saw in my bio and I like eating, which  you probably already saw in my bio. It seems like my favorite thing to do besides skate.  All right, so seven laws of teaching. They seem straightforward and people mess them  up all the time. This is a book written in 1884 and all classically trained teachers  should have read it. So I'm going to go through the laws and apply them to software. The law  of the teacher, the teacher must know that which he would teach, therefore know thoroughly,  clearly, and familiarly the lesson you wish to teach. Now because there are three types  of teaching opportunities, I'm going to go through them individually for this lesson.  First you have onboarding. And many people feel like onboarding is their personal, like  it's a one man show, it's not, it should be a team or company show. If you don't know  what you're supposed to be teaching during onboarding, you can't onboard someone. And  you can't make that decision alone unless you're the manager or the owner. So basically  there should be things that you're trying to teach people during onboarding, mostly  involving company specific information of the three types of information you have that  can be your science, the domain and the company. Company and domain are going to be big during  the onboarding process. Once you finish the six to eight week, they should have an idea  of what the company is about. They shouldn't be uncovering new company things as they roll  through. But the important thing is that you can't figure this out on your own. You've  got to have someone help you. If this is definitely a team issue. Now at Spreedly, my lead Ryan,  if he has touched anything, there's document on it. And I love that. Also if you touch something,  once you do document it, I hate that. So that was priceless coming in because there  was always documentation on anything that I needed. And so after I came in, then shortly  three more developers came on. And what we realized is that all of us, there was no onboarding  process, but all of us did the same things for the first six weeks. And so we had a process.  We just hadn't written it down. So what Ryan did was he went and he created a new engineer's  handbook. And this has been invaluable. The new engineer's handbook covers all things  from setting up your machine, what type of work assignments you're going to have, the  expectations like office hours. Basically what you need to know to have all those things  that people that have been in the company for six months to a year, if they've been there,  they kind of know all these things. You want those things in your handbook. You want to  answer as many unknowns about the company so you can get that off of their plate and start  really coding and talking about domain. So some other things that you can do during the  onboarding process will be you want to make sure they understand your dev process and  the working agreements on your team. For example, do you have a definition of done done? They  should know what that is and they should know what that is pretty quickly. Am I talking  too fast? I'm just going with Arthur's response. I'm not listening to anyone else apparently.  All right. Also present your style guide. You may not have one and I, it's okay, I'll  get on you, but if you have a style guide, it's nice for them to know how you want them  to write their code. And if you don't have one, I suggest you get one. If only for you,  you want to adopt one basically so people coming on know the expectation, not so that  you can hammer people over the head, although that's fun too, but you definitely want everyone  to know the expectation. Now you want to know how the team fits in the company as a whole.  That's an important thing for them to know with whatever team they're going to. Also  to understand how the developer fits in the team. Basically all of this is trying to  manage expectations. And then you want to tell them how the team deals with conflict  before the conflict comes up. It's already stressful coming on in the company. And if  you come on and there are, and you have conflicts right out of the gate, like that would ever  happen, it would be nice to know what the process is before you face it. Then you have continuing  education and mentoring. And the goal here, this is unbounded. So this will happen over  weeks and months, hopefully years if they like the team. And the point of continuing  education and mentoring is to take people where they are on your ladder, whatever level  they are, have them master those skills and also push them towards the next level. Engineers  want to grow. And so if they feel like you're helping them master their skill set and also  pushing them to the next level of their skill set, it's reassuring that they're not the  only ones driving their career. So you want to make sure that they know what the engineering  ladder is. You want to go over that, what your expectations are for them to move on  to the next level. Because everyone wants to move on. And if they don't want to move  on, you should probably get rid of them. Because people that aren't getting better aren't worth  it. I'm sorry, I'm very harsh like that. Style guide reviews are a great thing to do during  this time because most style guides, like for example Airbnb has a JavaScript style guide  that I spent a lot of time in at one point. And I enjoyed it because I like knowing why  people are making those style decisions. Now people can be flipping about style and just  not, you have to do this way. But a lot of times they have good reasons why they've made  those decisions. And so going over that with inexperienced devs is a good way for them  to make their own opinions. Because really what you're wanting them to do is acquire  strong opinions and hold them loosely. What that means is they should have an opinion  and be able to discuss other opinions and hopefully improve their opinion. And so this  continuing education should be helping them along that path. And then lastly, you need  a core book list and recommended reading list. So every company has things that they value.  And if you don't, when I was homeschooling all my kids read the same set of core books.  What this did for us is when we sat down at the table and we wanted to discuss something,  we could reference the same books. We want to talk about government. They already read  the Federalist Papers. They read the Anti-Federalist Papers. They read John Locke. They read Rousseau.  We could hit any of those and all my kids will know what you're talking about. It's  awesome when you can talk to your kids, when you can talk in a group and you all have the  same reference points. So having a core book list can help get everyone on the same page.  And that's very helpful for having better opinions, holding them strongly or holding  them loosely and being able to defend those decisions.  And then the last for the law of the lesson, the routine questions. So on these, you need  to have the answer or know how to find the answer. Be able to teach them the process  and how they're going to find that answer because you can't plan this out. And the same  teaching goals apply. You need to be reducing unknowns and demonstrating problem-solving  skills. So if in the course of a routine question, you realize they're missing something that  they should already know, you should fill in that gap right then because every time you  fill in an unknown, developers are more happy and they're more productive.  The second law is allow the learner. The learner must attend with interest to the material  to be learned. Therefore, gain and keep the attention and interest of the pupils on the  lesson. Don't try to teach without attention. This comes down to hiring. You need to make  sure you're hiring people that want to learn. But also, you need to provide an environment  that is conducive to learning, which means you need to welcome questions. And the reason  why you need to welcome questions is because questions expose unknowns. And you can't fix  an unknown until someone's told you they have it. So you definitely want to foster that  environment, which means that if asking questions is good, everyone should be doing it. It shouldn't  just be the more inexperienced. You know, they should see seniors asking questions.  It's encouraging to them to make sure they ask theirs. Now, if you have an experienced  developer who's not asking questions, one of two things is going on there. One, they  haven't reached their full potential. Or two, they are just really good at Google. The  second one is acceptable. The first one is not. So another thing that we did at Spreeley  is we made a Slack onboarding channel. And this allowed people to be able to go into  a more private room with you have your mentors and just your onboarding people there. And  they can ask the questions without having to expose all their unknowns to everyone in  the company, which can be, you know, rough after a few weeks. So, but I've gone through,  you know, imposter syndrome is very common in our industry. Any level can face it. And  so I've gone through and I've actually scripted. I had some really great actors and actresses  actually play this out for me. I scripted this great little talk you can have with  all new devs about imposter syndrome. No one knows what they're doing. This is a very  helpful conversation. Everyone should hear this. Which is all faking it until we figured  out. I mean, and I realized that some of us know things, but there's so many things that  we don't know. And I think that we really need to make sure people realize how much  experienced devs don't know. The Google did this study to figure out what made teams effective  and what they came up with. One of the things, I'm not going to go through all five, but  one of the things was psychological safety. And basically that is defined, can we take  risks on this team without feeling insecure or embarrassed? And questions can be considered  a risk. So if you can't ask questions without feeling insecure or embarrassed, your climate  is bad. You need to fix that. So I also have this theory. I think this is my theory someone  might have said before. So I'm not crediting them because I don't know. The number of regular  interactions someone has with a team should improve their psychological safety. And I'm  going to give you two scenarios. First, a developer has 40 interactions with their team,  and of those 40, they're all questions. And the second developer, they have 200 interactions.  They ask more questions. They ask 60, but they've had 200 interactions. Now that first  developer that only had 40 interactions, they're going to start becoming very self-conscious  about asking questions. Because every time they ask a question, it's a reminder that  all they ever do is ask questions. And that can get heavy when you're coming on someplace.  You want to have something to offer. You want to have something of value. And your questions  are just a drain on those around you. And some people won't feel that, but some people  will. And you want to watch out for that. The person that has 200 interactions and 60  of them are questions. The questions are part of the flow, but they don't define the flow.  And this is where team building comes in handy. You need to have some interaction. And it  can be meals. Meals is great because everyone has to eat. And you want to make sure that  your activity is inclusive. So drinking, I like it, but not everyone does. So you want  to do things that everyone on your team will enjoy. Water cooler chats. It's nice to have  a kitchen where you can kind of go out and hang out with people and chat with them. You  need to have more interactions than just questions all the time for the new people at your company.  A foosball ping pong. Where else am I right with that? Company events and parties. And  then, you know, team building type events. So basically you want to provide some interaction  for your new people at your company that don't involve them, have to ask questions about  things they don't know constantly. Pro tip. Don't start explanations with clearly or obviously.  It's a bad juju. Just don't do it. The law of the language. The language used in teaching  must be common to the teacher and the learner. Therefore, use words understood in the same  way by the pupils and yourself. So there are two keys to success for this. Don't use industry  specific acronyms or domain specific acronyms that frustrates people. They don't know what  you're talking about. And it's disheartening. And we do it a lot. And then you want to define  your terms as you go. At Spreely, we developed a repo that had a glossary of terms in it.  And that was really helpful. So we would point the new people to the glossary. We would try  to make sure we're explaining acronyms as we go. But at the very least they had some  recourse to go figure out what acronyms were when they got confused, when they saw things  in docs, and they didn't know what it was. So you want to make sure that you're using  the same language. And I'm going to get an example from when I was teaching math. Number  12 here. One day, this is like step graphs. That's basically what this chapter is on.  And a student raised their hands. And it turns out that they had never been to a post office.  So they couldn't understand the problem. The language of the problem was beyond them.  They didn't know what was going on. And so in order to... It made me feel old, which  was not nice. And I could have just explained what a post office was, but that would have,  again, made me feel older. So I changed it into text messages where the first four or  like, you know, 120 text messages are this much money and then additional money for every  block of 15 text messages after that. At this point in time, phone plans weren't doing the  whole unlimited text thing. So they understood the problem and they were able to solve it,  but they really needed to understand what the problem was there.  The law of the lesson. The truth to be taught must be learned through truth already known.  Or begin with what is already well known to the people about the subject and proceed to  the new material by single easy natural steps. So this just means you have to teach from  the known to the unknown. And we do this all the time. If someone asks what a word means,  we don't define the word they don't understand with more words they don't understand. We  define that word with words they do understand. So when you're working with a new developer,  you want to make sure that wherever you're starting your explanation, they actually know  where you are in that pipeline. So if they're back here and you start here, your explanation  is useless. You have to make sure that you back up to where they are and some of that  is going to be you asking them questions. But I have an example of someone chaining  things together to help them learn something new. And it's not the greatest, but it shows  the chaining part. Michael Scott has an amazing mnemonic device by which he memorizes people's  names in the crowd. I don't know if you guys are office fans or not. Right? Your head is  bald, it is hairless, it is shiny, it is reflective, like a mirror. Your name is Mark. Yes, got  it, it works. So what Michael Scott is attempting to do here is chain things together. He knows  to learn something he doesn't know, which is a good idea. I wouldn't do that though.  Okay, so the idea is that you want to teach from the known to the unknown. Random factoids  don't stick. You have to make sure everything is cohesive. So when I was teaching math,  when a student couldn't complete this problem, I would ask if they could complete this problem.  More often than not, they couldn't. And you would think that by the time you got sophomores  and juniors in high school that they would be able to do that bottom problem. But most  of the time, if they had a problem with the top problem with algebra and fractions, they  actually couldn't do regular fractions. And if I started the explanation just working on  the algebra, they were gone. I had to make sure I backed up and went over fractions again,  which seems silly, but it's just reality. So sometimes I think of teaching like throwing  toilet paper at a wall, you know, and so you just throw a bunch of information at people  and you see what sticks. And that's kind of, it is what it feels like sometimes, but the  reality of the situation is that that kind of takes away that you can affect, you can  change the effectiveness. And how you change the effectiveness is when you're throwing  the information and it actually attaches to something already. If they already have information  and you throw more information that attaches, then it will actually stick. If you don't,  it's just all wasted words. And it's frustrating too, because what happens is if someone asks  me a question and I explain it to them, and at first like let's say Arthur asked me a  question and I start explaining out here. Now the first time I do this, he might say,  wait, I don't understand how you're out there. Like, and he'll pull me back to where he  knows, because, you know, he's communicating. But if I continually end up in front of him  all the time, way out here with my explanation, he's going to start feeling the need to save  face, because he's like, I never, I never, I don't know what they're talking about all  the time. And so then you just going to get this, oh yeah, yeah, yeah. That's not good,  okay. So you got to make sure that you're starting where they are, because if once people  go into save face mode, then you've kind of lost the battle, because now they're just  trying to make sure that you don't think that they're stupid. And then, you know, see past  rule on that. You want to make sure you have an environment where they can ask questions,  where they feel like they can learn and have some psychological safety. The law of the  teaching process. Teaching is arousing and using the pupil's mind to grasp the desired  thought or to master the desired art. Therefore, stimulate the pupil's own mind to action.  Keep his thought as much as possible ahead of your own expression. Placing him in the  attitude of the discoverer or anticipator. Most of us know this by like, Socratic method  type things. And so, you're trying to make sure your students are making the lessons  their own, not just don't tell them. So, I think the best value as teachers that you  can provide to students or people that you're training isn't to provide answers, but to  teach them the right questions to ask. Just like, if you became an excellent Googler,  you're just more effective, because you know how to ask questions. That's basically what  makes people good at Google. What question do I ask? So, but it can be time consuming  to teach people how to ask questions. So, I want to go over first the benefits to just  answering questions. Because there are a few. Just answering questions. It's easy. It's  fast. And I think number three is the most important one. It makes us feel smart. And  it's even better if we can make them not feel smart. You know? So, like, if you're just  answering questions, you have to ask yourself. If you're playing this little passive aggressive  thing, where answering questions and not really providing the backdrop for someone not to  answer that question again, it's kind of passive aggressive and you need to knock it off, because  it makes people not like working with you. And also provides job security. So, that's  another big benefit here. So, just answer questions. These are the things you'll get  from that short-term gratification, but long-term it's bad for the team. So, in education, we  use a thing called question-answer flow, which is basically where I ask a question and you  give me the same answer. And we do this over subject matter. And you end up memorizing things.  And when someone asks a question, they'll automatically know the answer. So, it's like  predictive text, but it actually works. You want to reuse the same words verbatim. It  triggers the person to start hearing your words before they ask the question. And it's  extremely effective for math education. So, here's some examples. I would ask my class,  what does of mean in math? Now, I'm sure many of you probably already had this question,  like, means multiply. And you definitely want people to have that, this is, what do you  do here? And they know the answer. So, you're basically teaching them how to ask questions.  When they read a problem and there's of in it, they're like, oh, of, I have to multiply.  What's the first thing we try to do when we see an algebraic fraction? Factor and reduce.  Now, this is a harder one. People don't like fractions and people don't like algebra, so  put the two together and they just hate that. So, at least if you give them some way of  dealing with that fraction, the first thing you want to do, try to factor, try to reduce.  At least they have something in their toolbox to address that. So, when I joined my first  team that had a working agreement for testing on a PR, I would put the PR out and I'd ask  for a review. Someone say, you wrote test for that, right? Like, damn it. You know,  nothing else. Put it out there. But that only happened a couple of times before. I'd be  like, I'm going to push the button. You wrote test for that, didn't you? No, darn it. So,  that question-answer flow, using the same type of flow to get someone on board is very helpful.  So, new developers need to hear that flow, even experienced new developers need to hear  the flow because the stack is different. So, you want to take them when you're working  through a problem with them or you're working through any issue. What you want to do is  talk out loud and tell them where you'd start looking. You know, like when you call customer  support, is the machine plugged in? Yes, the machine is plugged in. You know, they're starting  debugging from the beginning. But when you start working on a code problem, we already  have all these questions that we're asking ourselves, but we're not telling people that  we're asking ourselves and resolving the question. So, when you're teaching someone, you want  to ask the question out loud and resolve it so that they can learn your question-answer  flow and they may not adopt all of them. But when any questions that they adopt will help  them tremendously in their debugging efforts and also to understand that you're basically  asking your questions to get to your answer and they should mimic you on that.  Alright. So, although repeating answers is really great and helps people memorize the  answers and have that available, if they don't understand your answer, repetition won't help  at all. So, you need to go back to make sure you're using words that they understand and  that you're starting somewhere that they can actually follow you. And then those types  of answers, when you repeat them, they actually do help.  The law of the learning process. The student must reproduce in his own mind the truth to  be learned. Therefore, require the people to reproduce the thought the lesson he is learning.  Thinking it out in various phases and applications until he can express it in his own language.  I think the takeaway here is that we definitely want people to make this information their  own and we want to give them a chance to apply it. And we also have to accept the fact that  people have different learning styles. So, you have social learners and you have solitary  learners. And although a company might have a certain culture of mostly pairing or mostly  working alone, you want to make some accommodation for people, especially in the ramping up on-boarding  period to do things that make them comfortable. Because having to learn a bunch of stuff and  being comfortable is very difficult. If you have to learn a bunch of stuff, but you can  be somewhat comfortable, it's just so much easier. So, if you have people that like pairing,  accommodating them a little bit on the pairing, if you're not a pairing shop, it would be  good. And also, if you have solitary learners, but you're a pairing shop, you might want  to give them some time on their own just so that they can feel comfortable learning the  stuff and feeling comfortable in that situation. You can't talk understanding into people.  And this is something that I saw when I was, three years ago I started skating so I could  play derby. And basically you would go to practice and someone would volunteer to teach. And  the best teachers were the teachers that taught you your lesson and then they let you work  on it. And it was a mess. I mean, you know, you're all over the place. But the fact of  the matter is it's a physical activity and no matter how much you understand the physics,  no matter how much someone tells you how you're supposed to plow stop or how you're supposed  to hit someone, you just have to hit them a lot to get that down. So, the idea is that  you can only tell someone so much and then you've got to give them time to work it out  and you can't talk it into them. And people make the mistake of, I'm going to give them  the benefit of the doubt that they're trying to help because the flip side of that coin  is that they just like to hear themselves talk. So, if you find yourself talking a lot and  someone's glazed over, ask yourself, am I helping them or I'd just like to hear myself talk  because you're going to have to adjust that. The law review and application. The completion  test in confirmation of the work of teaching must be made by review and application. Therefore,  review, review, review, reproducing the old deepening its oppression with new thought,  linking it with added meaning, finding new applications, correcting any false views and  completing the true. I realize all these laws are like 1880s English. So, I apologize. But  the idea here is that you want to review with people. I think PRs are probably one of the  best ways to review to go over the work to make sure that they're doing things according  to style, guidelines or maybe just design, things that how you want them to design. But  in order for review and feedback to be helpful and effective, the developer needs to understand  the expectations and the evaluation standard. So, if you have not made these things clear,  you need to because it's just going to, it's going to really, this is probably the number  one frustrating thing for me is if I'm not sure what you want from me, because I really  want to do a good job. I don't want to just do a good job. I want to blow it out of water.  But if you don't tell me what that looks like, like what is it if I just, you know, if I  meet the bar, where is that? If you don't tell me where I can meet the bar, then I can't,  I definitely can't jump over the bar. And that's really what I want to do. And the  five keys to a successful Google team, one of the keys was structure and clarity. So,  our goals and execution, goals, roles and execution plans on the team clear, because  if they're not, you should fix that. Your team will be more effective. And then you  need to establish a feedback cycle. Make sure that that new developer has a way to talk  to, a comfortable way to, for you to check in on them. And the feedback there should  go both ways. You should be able to give them feedback about how they're doing. They should  give you feedback about how you're doing. I coached a volleyball team from middle school  through high school. And at the end of six years, we won the state championship. And  it was one of the things when I look at other teams we played over those years, because  we're just a bunch of homeschool girls. Some of them literally couldn't run when I first  got them. So, like, to take them from that to this championship team was, it was an  amazing journey. And I watched a lot of other coaches with much better players, taller players,  you know, club players. And we would just knock the snot out of them. We just beat them  up. We made them cry. It was awesome. I mean, like, seriously, that is like the golden standard  of coaching. Like, can you make the other team cry? I'm serious. So, I would watch  these other coaches and I realized that really it wasn't a failure of the players. The players  on those teams were fine. The coaches really didn't know how to use them. And the reason  why is because the offense, because there is offense to volleyball, the offense that  they run in Iran or the defense, there was some breakdown. The kids did not have the  vision of the coach. And so, for six years, literally six years, I had the same exact  huddle talk, so much so that if you're on my team for more than two months and I do  this, you know the huddle talk's coming and you know exactly what I'm going to say. I'm  going to tell you the three things you have to do to win a volleyball game. And then when  we're in practice, I'm serious. And so, when we're in practice, we'll be serving. And I'm  like, you go back there and you serve 10 serves and you better get four in because if you  don't get four in, you know, like one, two, three, four, don't go in, you're letting your  team down. I'm very clear about my expectations on that team because that is just the nature.  If you want to win, this is what you have to do. So, my standards are really clear.  I'm very good about giving them evaluation criteria. They can take that criteria and  when I'm not there and the ball doesn't go to target when they pass and they shake it  off somewhere, they know in their head, they already hear me yelling at them. So, they  have that criteria and I'm telling you right now, those girls delivered. I mean, we whooped  up big time. It's awesome. All right. So, the feedback cycle, I just covered that. High  performers love to smash expectations. So, you're going to have like A developers, B  developers, C developers. If you want your A developers to really take off, you better  tell them what your expectations are because they're going to be aiming above those and  they can't aim above what they don't know. And lastly, not only does being a good teacher  help people learn, but it will help you learn too because when I'm talking with someone  now as a teacher, if someone says a word that I don't know, I'm just like, I don't know  that word. You have to explain it to me because I realize this is a breakdown in the teaching  process. This isn't a Mickey's ignorance. I mean, I am, but that's not the point. The  point is that they're trying to teach me something. They're trying to communicate something and  I can't follow them because I don't know the words they're using or I need to say, you  need to back up because I don't understand. And as a, once you understand how the teaching  process works and the learning process works, you'll stop people and you will be able to  be a better learner. Any questions? I know that I'm done and anyone can leave, but I  don't want to not answer questions people have. We're good? Awesome. Thank you. You've  been great.  Thank you.
Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_0_47.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_48_119.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_120_227.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_228_1007.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_1008_1331.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_1332_2147.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_2148_2903.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_2904_4439.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_4440_5315.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_5316_6719.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_6720_7355.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_7356_9455.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_9456_10583.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_10584_11999.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_12000_14699.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_14700_15383.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_15384_15803.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_15804_17771.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_17772_20327.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_20328_23783.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_23784_23915.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_23916_24551.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_24552_26831.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_26832_26963.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_26964_27095.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_27096_27287.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_27288_27539.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_27540_28283.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_28284_30827.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_30828_31019.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_31020_31367.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_31368_32351.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_32352_33707.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_33708_35147.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_35148_35327.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_35328_35807.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_35808_36023.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_36024_36155.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_36156_39011.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_39012_40415.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_40416_41363.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_41364_42167.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_42168_42239.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_42240_43727.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_43728_45023.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_45024_45599.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_45600_47195.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_47196_48671.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_48672_49691.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_49692_50471.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_50472_54263.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_54264_54359.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_54360_54731.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_54732_55715.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_55716_56147.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_56148_56267.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_56268_56399.png Quit_Frustrating_Your_New_Developers_-_Tips_From_a_Teacher_56400_56413.png