 I did almost get flooded into Detroit, which I think was the universe's way of telling me, you really don't want to talk right after Dave Thomas. But I made it, so I'm going to do my best. I'm here to talk to you about growing junior developers, which I think is a really relevant topic for the Ruby community because you are the ones getting all the people coming out of the boot camps. So there are a lot of juniors in Ruby, and I'm really excited to talk to you guys about this. So before I get started, I want to thank you all for hanging out with me a little bit today. I always do this thing at multi-track conferences where I secretly hope nobody will show up to my talk, and then I can just let go and go to other talks and it's fine. I didn't have that option today, but I'm still really glad that you're here. I do love this talk a lot. I had been saying this year that I'm tired of giving this talk, that's not actually true. It's a big talk for me because it's a really emotional one because this is the culmination of three years of work that was really important to me. So really quick, this is who I am. I'm Erica, I am EA Carlson, everywhere on the web that it matters. I'm a software developer. Primarily iOS these days, I have also built enterprise software in Java, which I really love and JavaScript, which it's complicated. I work at Detroit Labs in Detroit, Michigan, and I'm currently the director of our Apprentice and Training programs, which is why I'm here today to talk to you. In 2014, at Detroit Labs, we created an experiment. We were having a really hard time hiring enough developers. We are a native mobile company, so we do iOS and Android, and it's very hard to hire mobile developers. They're very expensive and they can get paid to go work somewhere where it's not winter nine months out of the year. So we thought, okay, usually what we do is hire web developers and teach them mobile. What if we took that a step further? What if we could hire people who had no prior experience, put them through say three months of training and then hire them afterward, and then continue to grow them within the organization as Apprentice Developers. That was about all the planning we put into it the first time. We just figured we'd give us a shot, see if it was even possible, and go forward from there. This is not a pitch. This is background so that when I say a whole bunch of stuff to you guys in the next few minutes, you'll understand where I'm coming from. Since 2014, we've trained 46 developers through our programs as of last week. 12 additional developers through our partnership programs. This then says a bunch of stuff about what I've done, which sounds really professional and like I have my stuff together. But in reality, I've spent the last two and a half years making mistakes. I've messed up big time. I've cleaned up other people's messes. I have put out fires. I have started a dumpster fire or two. I've talked, I've learned to listen more than I talk. A lot of people have cried in my shoulder, one person threw a phone at my head. It was the Nokia brick phone too, like we're not messing around here. But mostly I've encouraged and cheerleaded and pushed and supported and fought really, really, really hard for people that I believed in. Mostly I've learned and this talk is intended to share some of that learning. This is the only interactive thing you have to do all like this entire next 20 minutes, I swear. I'm just curious. How many of you would consider yourself to be senior developers? Okay, good chunk of the room, hands down. Somewhere between junior and senior, raise your hand. Okay, and junior, hands up. Nice, that's a really good mix. Usually I get really a lot of juniors and a lot of seniors and a lot of people who don't think they're mid-level. Anybody not a developer? Cool, I'm glad you're here too. If you're at all interested in helping people grow or in growing yourself, I promise there is something in this talk for you. I'm going to go over a whole bunch of stuff, but these are some of the big points. I'm going to talk about choosing the right junior person for your team. Our selection process is what I consider to be our secret sauce. I'm doing that part right, sets the stage for everything else. I'm going to talk about getting off to a good start, because if you don't do that, you can pick the best person in the world and you might still lose them. I'm going to talk about studying and managing expectations, which is something that we learned we were really bad at. I'm also going to talk about feedback, which is one of my favorite topics and could be a whole talk all by itself. Conflict resolution. You don't have that on dev teams, right? Other things that we have not done well, but have learned to do better. So step one, when I started this program, I was wide-eyed and super optimistic and thought, anybody can be a developer. A lot of people can become developers. Some people can't. Moreover, not everybody can become a successful developer and an effective team member. And we were looking for both those things. A junior developer's past experience, if they even have any, may or may not tell you very much, so you have to learn to look for potential. Talent is great. I've seen a lot of talented people. We typically get two to 250 applications for 10 spots any time we run a program. So a lot of people have come through our doors and gone through our process. I have seen a lot of people with a lot of talent. But I no longer think it's the most important thing or even necessarily a requirement. What I look for is persistence because what we do all day is solve problems. We have to be curious. We have to be thoughtful. And we have to be, I'm gonna go with bullheaded, right? Like we have to come up against a problem and not quit. And so our interview process is actually designed to look for people who have what we call in Detroit grit. People who see a problem and go, oh, I'm gonna sit down and I'm gonna figure this out and it doesn't matter how long it takes me or what I have to do to get to the solution. I've learned that people who run out of the interview crying are not usually the right fit for this field. We've been lucky so, well, I'm not gonna go with lucky. I'm gonna go with we've studied this and worked really hard to figure out what makes a good developer. 88% of our apprenticeship graduates are still working in the software industry and most of them are still with us. And that selection process I think is key to that. Looking for potential is hard. So I look for people who hit a wall and they dig in. I look for people who turn on when they get stuck. And I look for people who have the patience to look at a problem from all angles. I went to a very, very tiny college in the middle of a cornfield in Western Michigan. And its motto is strength through choices with the challenge which I think is actually a pretty good way to describe being a good programmer. Next I look for teachability. And what I mean by that is people who aren't afraid to ask questions and people who are willing to engage in the process of finding an answer. Asking questions is great. If you don't ask questions, I don't know where you are. I don't know if you understood what just happened. I don't know if you're struggling. So I need people who can ask questions so that I'm not hunting them down to figure out do they know what's going on. But I also teach apprentices and junior developers to ask questions in a certain way. When they come to us, their teachers, they have to explain the problem. Really explain it because if you can explain the problem then you understand the problem. And if you don't understand the problem then we're not even at the point of going to an answer yet. We have to understand what's wrong. It's a big part of our job, right? Figuring out what the problem is. So they have to explain the problem. They have to say I've tried this and I've tried that and I've tried this. And my current hypothesis is this. What's the next step? That's what I mean when I say engage with the process. I don't mean come to me and say what's the answer. Cause yeah, I know the answer and I can give you the answer but that's not gonna teach you anything and it's not going to make you a good developer down the line because down the line you're not gonna have necessarily somebody who can give you the answer. You're gonna have to know how to go through this process of saying, okay, I've defined my problem. I have a hypothesis. Here are some things that I could do. So we try to teach them to internalize that from the beginning. We also place as much emphasis on soft skills on technical ability because really there's not a lot to evaluate technically when somebody doesn't have any programming experience and it is an adventure to try. Let me tell you what. So what I look for, they accidentally all start with C but I did not do that to be gimmicky. I look for communication. I look for collaboration. And I look for conflict resolution because you can train someone to be a better developer. You can train them to be a developer period. You can't necessarily teach them to be a better human and you probably don't wanna try because you have software to build. So it is possible to grow soft skills. Absolutely. I have done it myself. I have had colleagues do it. That's the thing you can do but when you're starting out with somebody who already has so much to learn it's best if the soft skills can be there. Lesson two. This could be a whole talk all by itself, right? Because the right fit means a lot of things to a lot of people. To me, this is about getting buy in from the team the junior developer is going to be joining because that team will determine whether that junior developer is successful or not. So they have to buy in. They have to say yes, this is a person that we will invest time in, that we will slow down our own work for, that we will answer the same question 15 times for, that we will be patient with, that we will coach, that we will mentor and that we will grow. That is a lot to ask from somebody. So if you're going to ask that, they should believe in the person that they're going to be doing all those things for. I think that the right fit brings new strength to a team. As we go through these slides, you'll notice that a lot of the things I say don't just apply to junior developers, they apply to all of us. And that's something that we learned as we went through the process of growing 46 junior developers. They taught us probably more than we taught them. So a right fit brings new strengths. Maybe they ask good questions. Maybe they're just really enthusiastic and they're like, I got a for a loop to work and you're like, yeah, you did it. Maybe they help you learn to give better feedback because you cannot make a junior person successful without a good feedback loop. Maybe your team is really siloed and they teach you how to knowledge share. So I look for somebody who is gonna help a team grow. Expectations are the framework for everything that comes after them. If you don't set fair, clear, realistic expectations for everybody before a junior person joins the team, you are likely to be in trouble. If a senior team member or multiple senior team members are expected to dedicate time to pairing and coaching and mentoring, first talk to them, make sure that's the thing that they can and want to do, and then make space for them to do it. One of the big mistakes we made the first time we did our program was we expected our senior developers to keep doing their jobs and also mentor a bunch of new people. They weren't very happy and I don't really blame them. So maybe it's your senior person is gonna do 75% of client work that week and then 25% time mentoring and pairing, but make space for them to do it or they won't be successful and they will also resent you. I like to seek input from the team and say how will we know this is working? We think we're gonna go this way, we think we're gonna say you'll spend this much time mentoring, we think you're gonna provide this, we think you're gonna do that, but what if in two weeks that's too much or it's not enough? So create a feedback loop once you set those expectations. You never, ever, ever wanna be in a position where somebody says I didn't know I was supposed to be doing that or that wasn't my job. Unclear and miscommunicated or just straight up not communicated expectations or the foundation of so many problems for development teams. And effectively integrating a junior person is no exception. If you don't set and manage expectations with the team, that can completely trash the rest of your efforts no matter how well you do on everything else. So find out what kinds of questions your team has. Find out what kind of concerns they have. Am I expected to put in a whole lot of time? Am I expected to teach this person? Am I gonna be held responsible if this person fails? Find out what's out there and make sure you know what the fears are before they morph into developer-eaten monsters. It's equally important to set expectations for junior developers. A junior person coming into a team has two assumptions. Everybody else knows more than them and they are probably going to get fired tomorrow. So try to take away some of that. Let them understand what their role is going to be, what kind of work they're going to do, who is going to answer the 18,000 questions they have in the first hour, what kind of performance an output is expected over time and how fast they're supposed to progress both in terms of the work that they do and how independently they can do it. Unknowns create anxiety. Anxiety impedes performance. So eliminate as many unknowns as you possibly can. Raise your hand if you love pair programming. Oh, that is more than usual. Raise your hand if you hate pair programming. It's okay. Yeah, all right, I see you. Raise your hand if you're somewhere in the middle. I'm somewhere in the middle. That said, pairing can either be the absolute best thing for a junior developer or the worst. At its best, pairing is a perfect teacher. My first six months in the industry, I paired with the guy who had been doing Java for 15 years and was a really good teacher and knew how to do this really infuriating thing where I would ask him a question and he would go, I don't know, what do you think? Maddening, but effective. My learning trajectory in that period was faster than it has been at any other point in my career. That experience was phenomenal. At worst, period is a destroyer of egos and relationships. I have put junior developers on a team and watched them ostensibly pair with somebody who was going, got that? Okay. And they're bored and then they're on their phone and then they're disengaged and then they don't feel wanted and they don't feel involved and they're definitely not wearing anything. And also, they're resenting that person and if that person is doing this, they're probably resenting being in the pair too, right? Bunch of issues there. So pairing from the start is one of the fastest, most effective ways to ramp up a junior developer who is new to the team, new to a language or platform or new to the industry. Pair juniors with more experienced developers, they don't even necessarily have to be senior. They just have to know more than that person who are good communicators and who have an interest in mentoring. I think that being a senior developer should by definition involve some degree of teaching. I think that's part of the deal. But not everybody feels that way and not every company works that way. So make sure that the people that you pair up with juniors really wanna be coaching, really wanna do some teaching. Set expectations for the pairing because junior senior pairs can very often turn into shadowing where the senior person does all the work and the junior person kinda nods along and internally they're going, oh my God, I get none of this when I'm getting fired tomorrow. Juniors should be actively navigating and driving during pairing sessions. Pairing partners should encourage questions and provide direction for sure, but not always give answers. That whole, I don't know what do you think strategy is really infuriating but really effective. As the junior person gains skills and confidence, they should be increasingly responsible for figuring out answers on their own. What you are doing when you pair with somebody who's junior is you are creating a scaffold. You're asking them questions that eventually they will ask themselves. Eventually they'll go through this whole process and they'll have it internalized, but for now they need you to teach it to them because coming into this field is ridiculous. There is so much knowledge. You don't even know what you don't know. You don't even know what questions to ask and that is terrifying. So this gives them structure and gives them guidance and eventually they'll be able to do all of this stuff on their own. This is one that I'm still working on. I haven't figured out the perfect balance here yet but I know it's important. Junior developers need structure to thrive especially at first. That means clear expectations and goals, e.g. you will not get fired if you do these things. It means assigned tasks. It means accountability. It means supervision and it means regular feedback. I work at a flat organization with no managers. We are terrible at structure. We just don't do it because up until we started this program we really only hired mid level to senior people who could be thrown in the deep end and would figure things out. And we're interested in doing that and did not want to necessarily be told every day here's what you will do, here's the expectation. So that worked for us. It emphatically and disastrously did not work for people who were brand new to the field. We figured that out the hard way. So we had to figure out how to create some structure. That said, some of the best days in our program are our Wednesday hack days where I will group up our apprentices in groups of two to four and they get to build whatever they want within certain constraints. I'll say, okay, your app has got to cover these three things that we learned this week. Other than that, go wild. And I see the most creativity and the most collaboration and the most excitement and they usually are at home slacking me at 10, 30 that night still working on the thing that they built that day because it's theirs. So that degree of freedom, accelerated learning increases motivation and enthusiasm. I think that's really valuable. Giving a person time to work on a personal project can significantly build their skills and their confidence. They're gonna go explore things that you would never even have thought to teach them. So I think that's a valuable piece too. All right, positive feedback. I was, you know, feedback used to be just one big slide all by itself. It's not anymore because positive feedback is like the redheaded stepchild of the education process. It gets left out so very, very often and is so important. Positive feedback tends to get lost in the shuffle because we're so focused on growth and improvement because there is so much room for growth and so many things to improve and that is true, but saying to somebody, you did a good job. That thing you did was great. Give us more of that. Build confidence. Improves collaboration. I really wanna work with somebody who told me I did a great job yesterday. Improves team relationships and increases motivation. Our CEO is one of the best business people I've ever met, but he's not super touchy-feely. So when he sends me an email, which he now does because he now knows this motivates me and goes, hey, you killed it in that meeting. I keep that in my inbox and I look at it like three times a day. But it's motivating. When positive feedback is specific, when it's related to performance, something that you did. When it's timely, when it comes right after that thing, it's really, really powerful and really effective. Now there's a flip side to this. A couple of my junior developers went to work on a client site and they had this project manager who thought they were so great and they are so great, I'm biased, but they really are so great. However, every day she came in and like rained candy on their desks and told them how great they were. I'm not exaggerating. Like every single day, you're wonderful. You're so good. You're terrific. Everything's the best. And they loved it for like two weeks because they don't get that from me. And then two months later, they were just completely over it because the constant praise was meaningless because it wasn't tied to anything they had actually done. So positive feedback loses its impact when it's non-specific, if it's insincere, or if it has nothing to do with anything you did. It should be specific. It should be timely and it should be sincere. Growth feedback is a thing I came up with in the shower. First I called this negative feedback and then I thought to myself, gosh, that sounds terrible. And then I called it constructive feedback, which sounds like a nice way to say negative feedback. And then I came up with growth feedback. So this is the current iteration, it may still change. The reason I changed the verb edge a couple of times was that I once asked a group of developers, this is not your developers, this is like across the board, to tell me how they felt when I said the word feedback. Some of the responses I got included stressed out, nervous, defensive, that person's honest, and one of my favorites, horrified. Receiving constructive feedback is a skill. And most of us have not had the chance to develop that skill, so we pretty much do the thing that I do on roller coasters, which is squeeze our eyes shut and wait for it to be over. So I try to use the term growth feedback to at least reduce the stressful connotations of the term negative feedback. That said, no matter what you call it, growth feedback is still stressful and anxiety provoking for anybody who has a hard time receiving feedback, but it is almost always terrifying for junior people who are already so anxious about the performance. I'm not kidding about that, I'm gonna get fired thing. I do one-on-ones with our juniors every single week. And there was one week where all eight of them said, I think I'm gonna get fired. None of them were anywhere close to being fired for the record, but that was the anxiety. And that's a huge anxiety, right? Like that's not small potatoes. So you have to be careful about how you structure this because giving growth feedback is also a skill and most of us do it wrong. Most of us do it in the moment. And the quickest way to provoke a defensive, not listening reaction is to give significant feedback in the moment. When somebody has messed up, they already feel terrible. What they don't need is you to tell them how much they messed up, cause they know, and all of the ways that they shouldn't do that in the future, and remember all those times you told them not to do that? No. My good friend, Alex Harms, who works as an Agile coach, has a really nice process for addressing a crisis, which when you have junior developers in your team, you will have crises. Builds will break, things will happen, something might even get submitted to the app store that shouldn't. There's gonna be stuff, right? People are gonna make mistakes. So when that happens, address the crisis, recognize that it's probably not that big of a deal because we're building software, not, you know, okay, I mean, some of us are working for NASA, but most of us aren't. So it's probably not that big of a deal. With love and with courage. Celebrate when you fix the problem and rest. And then look for causes and talk about how to prevent it from happening next time. Effective growth feedback is thoughtful. You address the acute problem, you cool down, and then you address the bigger issue later and with intention. I like to give significant constructive feedback in a one-on-one setting. It's not usually a good idea to do that in the group or even within the context of the entire team. Sometimes I like to give it in advance, like in an email, I'll say, hey, we're gonna sit down and talk about this, but for now I want you to know that the concerns in the table are these things. That helps some people kind of have their initial reaction and process it and then come in and be ready to talk. I really, really, really believe in giving constructive feedback on a regular basis. It lowers the anxiety level. Like, who's not freaked out if the only time you hear feedback on your performance is like every six months? That's terrible, don't do that. So, weekly if possible, maybe every two weeks if you have to. It takes away the anxiety and it increases the likelihood that that person is going to take that constructive feedback non-defensively. I talked about one-on-ones. When we started this program, we didn't do one-on-ones at all. We just sort of, I don't know. There was not a lot of structure. Let's bring it that way. We had a 60% retention rate for our first class. One of the biggest things we changed for the second class was we added a weekly one-on-one with me. And this was not a how are you doing technically? That's for their technical mentors to talk about. This was a how are you doing person who has just quit their job. Uprooted their family. Taken a luster salary. Jumped into something they're not sure they can do. All of those things are huge. That is a lot to ask from somebody and then also come in and perform every day. So it was just, how are you doing? What do you talk about this week? For some of them it was nothing, smooth sailing. This is the best thing I've ever done. I'm so excited I wanna be a programmer until I die. And some of them it was, I love this but I don't know if I can do it. Don't know if I'm good enough. I'm really scared. I'm worried about this. I can't get along with this person. Our retention rate increased to 95% for the first class. And I don't think that was a coincidence. Junior team members can be hesitant to raise issues within their teams because see all previous comments about I might get fired. So better to just if I have a concern keep it to myself because I don't know what I'm talking about anyway. So if they have a regular meeting with a supportive person that makes it less likely that issues are gonna go undetected. And that eventually that person that you just invested so much in is going to quit because of something you never knew about. Supports really important to success. All of those adjustments are enormous. They can be stressful. They can be emotional. They can sometimes be overwhelming. I usually get at least one person in my in each class who is actively having a totally separate life crisis in addition to going through this program. So it's important to provide that support. This is like the ha ha obvious slide. But it's one of those things that we as a team were not necessarily good at until we incorporated a whole bunch of junior people and suddenly had to get better. Tensions and challenges are inevitable when you bring junior people into a team that has not had them historically or hasn't had one in a while or maybe had one and had a bad experience. So you wanna create a framework for problem solving by acknowledging upfront that issues are going to happen. And when they do, this is how we'll work through them. Ignoring problems, leave senior developers feeling frustrated and resentful and overwhelmed. And then they quit. And nobody wants their senior developers to quit. Failing to address issues leaves junior developers feeling unwanted and anxious, more anxious. Maybe hopeless because they're going, I'm the low man in the totem pole. There's nothing I can do to fix this. And then they quit. And then you lost your future senior developers. Issues that go ignored become toxic to teams. I was asked to come in and facilitate for a team of 23 which was his own issue, who were all working on the same code base who could not talk to each other. It reached the point where they couldn't discuss technical stuff, they couldn't discuss non-technical stuff. They all just sort of like, they were in their own area in the office and everybody else just kind of avoided them because there was so much tension and anger like coming off of them in waves because they had so many issues that they hadn't worked through. And in the facilitation, all I could think was, every time somebody brought something up, they'd say, well, this is a thing. This is a thing. Here's a problem. This happens. And I'd go, okay, if this was addressed the first time it came up as opposed to, yeah, even the 15th time would have been better than the 127th time, which is about where we were at this point. It would never have blown up into this big of a problem. So address your issues up front. You will thank yourself later. Not a later note. All right, this is the feeling slide. Junior developers can bring so much to a team. They are like basically little balls of endless energy and joy. Enthusiasm, learning, commitment, excitement. They get excited about stuff that you forgot was exciting because you've done it so many times. We get so busy as developers, queuing stone that we forget we're building a cathedral. Junior developers remind us. The process of growing a junior developer creates so many opportunities for reflection, for feedback, for improvement, for growth, for you, not just for them, for you and for your team. In our case, even for your company. I've had so many senior devs come to me and say, man, I did not think I was cut out for this coaching thing, but this is the coolest ever because I get to watch this person have light bulb moments and they're so excited that now I'm excited again too. They remind me why I love to do this. Some of us are working on really world-changing stuff, but not all of us. A lot of us are working on enterprise software. You know, that we may or may not ever even get to see in action. Some of us are building startups that may succeed, that may be gone next year. We don't always, as developers, get to see the fruits of what we do. The biggest thing I ever worked on was the Domino's Pizza iOS app, which has, I think, about 8 million users, which is terrifying, by the way, because that's my junior dev code in the hand of 8 million users. And that's great. Now, I used to say, but all it really does is get people pizza, and then somebody said to me, hey, pizza can be life-changing, so now I don't say it anymore, but I just say, still, at the end of the day, that app is making a lot of money for a big company. It is getting people pizza, and that's great. But I get to walk around the office now and on every single team, there is somebody that I've taught and mentored and coached who did not know how to write a line of code when they came to us. And that's true for every other person at the company who's coached one of those people. They get to go, wow, I had a part in that. I made that. That happened because of me. One of our former apprentices who's now running stuff with one of our most difficult teams has the cutest son, and he calls me the second coolest person in the world, which is the best compliment I've ever gotten from anybody, but it's because I taught his mom to code. His mom's the coolest, which she totally deserves because she is. And I know that that made a difference for her. I know that changed her life, but what I never realized until he came up and informed me of this, as only seven-year-olds can do, was it made a difference for him too. So when you do this, when you invest in somebody, when you coach, when you teach, when you train, when you mentor, you get to know without a doubt that you made a difference. And I think that's the coolest thing ever. That's all I got. All right. It's all I got. It's all I got. Real quick, the pictures of suggestions. You can usually find me at The Food, otherwise on Twitter via email. Happy to talk to anybody, anybody with the stuff, anytime. I think we take about two questions. We're also gonna take a little brief break for a few minutes in burning questions. All right, so. Oh, you gotta bring questions. Mr. Fowler. What? Oh my God, it's so loud. What if they, the feedback thing, by the way, I think you could do a whole long talk about that. That was really great. And what if they don't know what they did wrong? Usually they don't. At least the first little while. So we factor that in, right? We know that, you may not even know this was a mistake. And so even growth feedback, we try to present very compassionately, like look, here's the framework for, we try to set expectations so that they do know when things are good and when things are not. But we're gonna assume that in a new field, new industry, all of these things, they don't. So the first couple of times I give feedback, it's just, look, I'm gonna assume that you did this because you did not know better. And that's okay. But here's what to do to know better next time. Now if that happens three or four times, then we have a different conversation. But yeah, that's how I try. Benefit of the doubt to begin with. Thank you. Yeah. Do you have, in your apprenticeship, do you have any sort of like a review process when they're at the end of shipping something? And what does that look like? Yeah. So the way the program works is we have 15 completion requirements. And some of them, about two thirds are technical. And then the other third is community related and project related and interpersonal stuff. So we have all of those requirements that they have to pass. And then any given project is code reviewed by senior developers on our team. So it's a whole team involvement for us. Thanks. Can we sneak one more? Yeah. Okay. Yes. I just had a question. As a junior developer entering the workforce, what should you look for? What should I look for in a team that would help me grow as a developer? So I would ask questions when you go in for your interview and say, hey, I consider myself to be a junior person. What is that going to look like in your team? What kind of mentoring will be available to me? How are you going to help me grow and ask them? And if they don't have anything in mind, that's okay. It's a conversation that you can have and talk about. But you want to set that up before you go and insert on day one. So again, expectation. And that's something that you can negotiate with the company before you even begin the job. Okay, cool. All right. Thanks, everybody. Thank you, Erica. We'll see if they can get it right this time. Three, two, one. All right.