 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 the grabs. Alright, so a little background on myself. I'm married young and have 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 the 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 conquer 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 a peer 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 the 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 Spreedly. 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 the development process. So, basically just company information. These are the three types of information that you need to know how to deal with. So, and there are two types of new developers. Going through all these types. Who doesn't like taxonomy? 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. I'm now in an overview of what, am I talking? Overview. If I'm talking and it seems like I should have done 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, it's freely right now. And, you know, 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, I don't know what you guys want me to tell you when you say how you're doing. Like, my stomach's upset, like I had a great breakfast. No. What we're looking for, so then I had to really quantify it. You know, 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 a 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. It's 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 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. 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. And so, experienced 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 the finish line, I've gotten the finish line tons of times, totally not knowing what I was doing. I can just do that again, right? 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 follow this, like, if you're preaching to the choir, that 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 spritling and 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 Postgres running. Well, I thought it was. I thought it wasn't, you know? 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, so she would send me helpful links. Now, you might, and so, like, at first you're like, ha-ha, and then you're like, damn it. I, 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. It's a, this is a book written in 1884, and all, 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. You know, 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's 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 he, if you touch something, he wants you to document it, I hate that. So, I don't know. So, that was crisis 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, 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 company or 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 at a 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, you know, 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, their skill set 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 it 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, but 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 it and unknown developers are more happy and they're more productive. The second law is the law of 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 know, 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 Spreely 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've 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 figure it out. I mean, and I realize 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's 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 a 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. We're all familiar with that. Company events and parties, and then 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. It 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 Spreedly 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 and 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, 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 give you 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 or 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 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, therefore begin with what is already well known to the pupil about the subject and proceed to the new material by single easy natural steps. So this just means that 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's useless. You have to make sure that you back up to where they are and some of that's 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. All right. Boaty. Your head is bald. It is hairless. It is shiny. It is reflective. Like a mirror, M, 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 won'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, 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'm never, I don't know what they're talking about all the time. And so then you're just going to get this. Oh 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 questions 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 a 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, 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 O in it, they're like, oh, 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 would say, you wrote test for that, right? Like, damn it. You know, nothing you can't pull down. 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 might not adopt all of them. But 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. All right. So although repeating answers is really great and it 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 type 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 onboarding 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'd 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 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 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 just like to hear myself talk because you're going to have to adjust that. The law review and application. The completion test and 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, you know, 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 like style guide wise or maybe just design, things that how you want them designed. 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 what 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 amazing journey. But 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. I mean, like 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. But I would watch these other coaches and I realized that really it wasn't a failure. 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 available, the offense that they wanted to run, 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 talks 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, 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 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.