My name is Mikki Riesenis, 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 MikkiRes, feel free to reach out. At Spreedly, I develop on ActiveMerchant 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 the 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 stay 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 gonna 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 gonna see this. All right, if I'm not growing, I'm unhappy again. I love teams, 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 gonna 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 gonna have routine daily questions. I'm gonna 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 gonna 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 it, 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. And now an overview of what, am I behind? There it is. Overview, if I'm talking and it seems like it's actually been another slide, just flag me down. I'm really cool with that.

Overview of teaching and training. So I'm gonna 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? Cause 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 the first week you'll just be talking with them and you'll say, and I say and then my lead Ryan says, how 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. 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. 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 wanna 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. I'm 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 where this is going. 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 gonna 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 gonna 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. 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, 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, 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 gonna be new problem solving skills that you're gonna have to learn for that stack

or for that company. And so, like for example, I went to Spreely and I'm setting up my machine and I can't get stuff to run. I said stuff, I was like good. I can't get things to run on my machine. And so, it's almost like, is Postgres running? Well, I thought it was, but 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 learn 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 then 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 gonna go on to the seven laws of teaching. I was a teacher, as you saw in my bio, and I like eating, which you probably are, you saw in my bio. It means 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 gonna 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 gonna 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 like computer science, the domain, and the company. Company and domain are gonna be big

during the onboarding process. Once you've finished the six to eight weeks, 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. 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, he wants you to document it. I hate that. So, you know. 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 gonna 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 it's okay. I won't 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 new, 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 out of the company, and if you come on and you have conflicts right out of the gate, like, that would never 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 flippant about style, and just, 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 a 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've already read the Federalist Papers. They read the Anti-Federalist Papers. They'd 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 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 gonna 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 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 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.

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's 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, and I had some really great actors, 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. We're just all faking it till 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. Google did this study to figure out what made teams effective, and what they came up with, one of the things, I'm not gonna go through all five, but one of the things was psychological safety, and basically that is defined as 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 it 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 gonna give you two scenarios. First, a developer has 40 interactions with their team, and of those 40, they're all questions. In 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 gonna 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 don't wanna just, you wanna have something to offer. You wanna 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 wanna 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 wanna make sure that your activity is inclusive, so drinking, hmm, I like it, but not everyone does,

so you wanna do things that everyone on your team will enjoy. Water cooler chats, it's nice to have a kitchen where you can kinda 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, 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 having 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 wanna 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 and they didn't know what it was. So, you wanna make sure that you're using the same language. And I'm gonna get an example from when I was teaching math. Number 12 here, one day, this is step graphs,

that's basically what this chapter's 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've just explained

what a post office was, but that would've, again, made me feel older. So, I changed it into text messages, where the first four or five, 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. 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 wanna 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 gonna be you asking them questions. But, I have a 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? I'm baldy. 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 wanna 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 infractions, 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.

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 gonna 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. So, then you're just gonna get this, oh yeah, yeah.

That's not good, okay? So, you gotta make sure that you're starting where they are because if, once people go into save face mode, then you've kinda 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 wanna 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 doing what you 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 wanna 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. 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 have 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, 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, 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. And then I'd say, yeah, I'll put it out there. If that only had to happen a couple times before,

I'd be like, I'm gonna 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. Like when you call customer support. Is the machine plugged in? Yes, the machine's plugged in. 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 then 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 pupil to reproduce in 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 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'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 and no matter how much someone tells you how you're supposed to plow a 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 gonna 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 gonna have to adjust that. The law of 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 truth. 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 the style guide wise

or maybe just the 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 gonna, it's gonna 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 the 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. In 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 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 to take them from that to this championship team, it was an amazing journey and I watched a lot of other coaches with much better players, taller players, club players

and we would just knock the snot out of them. We'd just beat them up. We made them cry. It was awesome. Seriously, that is the golden standard of coaching. Can you make the other team cry? I'm serious. 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 offensive volleyball, the offense that they 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 talk's coming and you know exactly what I'm gonna say. I'm gonna 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 wanna 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 gonna 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 gonna 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 wanna not answer questions people have. We're good? Awesome, thank you, you've been great.

Thank you.