00:00:13.130
Hello, everyone! Can you hear me? Great! I almost got flooded into Detroit, which I think was the universe's way of telling me I really don't want to talk right after Dave Thomas. But I made it. I'm here to do my best.
00:00:27.210
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 boot camps. There are a lot of juniors in Ruby, and I'm really excited to talk to you about this.
00:00:40.530
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 multitrack conferences where I secretly hope nobody will show up to my talk so I can just let go and go to other talks, but I'm still really glad that you're here. I do love this talk a lot; I've been saying this year that I'm tired of giving this talk, but it's not actually true. It's a big talk for me because it's really emotional. This is kind of the culmination of three years of work that was really important to me.
00:01:10.800
So really quick, this is who I am. I am Erika Carlson everywhere on the web where it matters. I'm a software developer, primarily focused on iOS these days. I've also built enterprise software in Java, which I really love, as well as JavaScript, which is complicated.
00:01:22.220
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 because we were having a really hard time hiring enough developers.
00:01:40.530
We're a native mobile company, which means we do iOS and Android development, and it's very hard to hire mobile developers because they are very expensive and can easily find jobs in more favorable climates. So we thought, okay, usually what we do is hire web developers and teach them mobile. What if we took that a step further?
00:01:56.580
What if we could hire people who had no prior experience, put them through, say, three months of training, and then hire them afterward 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 it a shot to see if it was even possible and go forward from there.
00:02:22.280
This is not a pitch; this is background so that when I share a lot of information with you in the next few minutes, you'll understand where I'm coming from. Since 2014, we've trained 46 developers through our programs, and as of last week, we added 12 additional developers through our partnership programs.
00:02:39.980
This then sounds very professional, like I have my stuff together, but in reality, I've spent the last two and a half years making mistakes. I have messed up big time, cleaned up other people's messes, put out fires, and even started a dumpster fire or two. I've talked, listened, and learned to listen more than I talk. A lot of people have cried on my shoulder, and one person even threw a phone at my head. It was a Nokia brick phone, so we weren't messing around! But mostly, I've encouraged, cheered, pushed, and supported the people that I believed in. This talk is intended to share some of that learning.
00:03:05.069
This is the only interactive thing you have to do for the entire next 20 minutes. How many of you would consider yourselves senior developers? Okay, good chunk of the room. Hands down. How about those who are somewhere between junior and senior? Okay. And juniors? Hands up! Nice, that's a really good mix. Usually, I get a lot of juniors, a lot of seniors, and a lot of people who don't think they're mid-level. And is there anyone here who is 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.
00:03:30.209
I'm going to go over a whole bunch of points, but here are some of the big topics 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), getting off to a good start, managing expectations, feedback, conflict resolution, and other things that we have learned to do better.
00:03:42.570
Step one, when I started this program, I was wide-eyed and super optimistic, thinking anybody can be a developer. A lot of people can become developers; however, not everybody can become a successful developer and an effective team member. 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 200 to 250 applications for ten spots every time we run a program. So a lot of people have come through our doors and undergone our process. I've seen a lot of talented people, but I no longer think it's the most important thing or even necessarily a requirement.
00:05:07.289
What I look for is persistence because what we do all day is solve problems. We have to be curious, thoughtful, and bullheaded, meaning we have to come up against a problem and not quit. Our interview process is designed to look for what we call 'grit' in Detroit, which means looking for people who see a problem and say, 'Oh, I'm going to sit down and figure this out.' It doesn't matter how long it takes me or what I have to do to get to the solution.
00:05:33.009
I've learned that people who run out of the interview crying are not usually the right fit for this field. We've studied this and worked really hard to figure out what makes a good developer. Eighty-eight percent of our apprenticeship graduates are still working in the software industry, and most of them are still with us. That selection process is key to that. Looking for potential is hard, so I look for people who hit a wall and dig in, who turn on when they get stuck, and who have the patience to look at a problem from all angles.
00:06:08.129
I went to a tiny college in the middle of a cornfield in Western Michigan, and its motto is 'Strength through Joy in the Challenge,' which I think is a pretty good way to describe being a good programmer. Next, I look for teachability, which means people who aren't afraid to ask questions and who are willing to engage in the process of finding an answer.
00:06:24.099
Asking questions is great; if you don't ask questions, I don't know where you are or if you understood what just happened. I don't know if you're struggling. I need people who can ask questions so that I'm not hunting them down to figure out what they understand. I also teach apprentices and junior developers to ask questions in a certain way. When they come to us, they're teachers, and they must explain the problem clearly because if they can explain the problem, they understand it. If they don't understand the problem, we're not even at the point of going to an answer yet.
00:07:00.059
We have to understand what's wrong, which is a big part of our job. So, they have to explain the problem. They have to say, 'I've tried this, I've tried that, 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 coming to me and asking for the answer because, sure, I know the answer, and I can give it to you, but that's not going to teach you anything, and it's not going to make you a good developer down the line.
00:07:34.590
Because down the line, you won't necessarily have somebody who can give you the answer. You're going to have to know how to go through the process of saying, 'Okay, I've defined my problem. I have a hypothesis, and 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 as on technical ability, because really there's not a lot to evaluate technically when somebody doesn't have programming experience.
00:08:02.080
What I look for are communication, collaboration, and conflict resolution because you can train someone to be a better developer, but you can't necessarily teach them to be a better human. You probably don't want to try because you have software to build. It is possible to grow soft skills. I have done it myself; I've had colleagues do it. That's a thing you can do, but when you're starting with someone who already has so much to learn, it's best if the soft skills can be there.
00:08:33.670
The second lesson could be a whole talk by itself. 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. 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; we will slow down our own work for them, answer the same question 15 times for them, and be patient and coach them.'
00:08:56.050
That is a lot to ask from somebody. If you're going to ask that, they should believe in the person they will be mentoring. I think that the right fit brings new strengths 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. That's something we learned as we went through the process of growing 46 junior developers.
00:09:14.410
They taught us probably more than we taught them. A right fit brings new strengths; maybe they ask good questions, or they are just really enthusiastic. 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 siloed, and they teach you how to knowledge share.
00:09:43.390
I look for somebody who will help a team grow. Expectations are the framework for everything that comes after them. If you don't set fair, clear, and realistic expectations for everybody before the 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 something they can and want to do and then make space for them to do it.
00:10:19.560
One of the big mistakes we made the first time we did our program was expecting our senior developers to keep doing their jobs while also mentoring a bunch of new people. They weren't very happy, and I don't really blame them. So maybe a senior person is going to do seventy-five percent of client work that week and then 25% mentoring and pairing. But create space for them to do it, or they won't be successful and 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 going to go this way.'
00:11:02.720
We think you'll spend this much time mentoring. We think you're going to provide this, and we think you're going to do that, but what if in two weeks that’s too much or not enough? So create a feedback loop. Once you set those expectations, you never want to 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, miscommunicated, or just not communicated expectations are the foundation of so many problems for development teams, and effectively integrating a junior person is no exception.
00:11:43.040
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 everything else. So find out what kinds of questions your team has. Find out what concerns they have: Am I expected to put a lot of time into teaching this person? Am I going to 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 monsters.
00:12:20.590
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 some of that away. 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 and output is expected over time, and how fast they're supposed to progress.
00:12:51.920
Both in terms of the work they do and how independently they can do it. Unknowns create anxiety, and anxiety inhibits performance, so eliminate as many unknowns as you 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; I see you! Many people are somewhere in the middle. That said, pairing can either be the absolute best thing for a junior developer or the worst.
00:13:24.630
At its best, pairing is a perfect teacher. My first six months in the industry, I paired with a guy who had been doing Java for 15 years and was a really good teacher. He had this really infuriating thing where, if I asked him a question, he would say, 'I don't know. What do you think?' Maddening but effective! My learning trajectory during that period was faster than at any other point in my career. That experience was phenomenal! At worst, pairing can destroy egos and relationships. I have put two junior developers on a team and watched them ostensibly pair with somebody who was disconnected and bored.
00:15:07.080
They would be on their phones and disengaged, and they wouldn't feel involved or wanted. They definitely wouldn't be learning anything, and they would resent that person. If that person is disengaged, they're probably resenting being paired too. It's a bunch of issues. 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 the language or platform, or new to the industry.
00:15:48.880
Pair juniors with more seasoned developers; they don't even necessarily have to be senior; they just have to know more than that person. They should also be good communicators and 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 the people you pair up with juniors genuinely want to coach and teach.
00:16:23.520
Set expectations for pairing because junior-senior pairs can often turn into shadowing, where the senior person does all the work while the junior just nods along, feeling increasingly lost and overwhelmed. Juniors should be actively navigating and taking charge during pairing sessions. Both partners should encourage questions and provide direction, but not always give answers. That whole, 'I don't know, what do you think?' strategy is infuriating, but it’s effective. As the junior person gains skills and confidence, they should be increasingly responsible for figuring out answers on their own.
00:17:07.350
You are creating a scaffold when you pair with someone who is a junior; you're asking them questions that they'll eventually ask themselves. They’ll go through this entire process and internalize it, but for now, they need your guidance. Coming into this field is daunting; there is so much knowledge, and there are questions they don't even know exist. That is terrifying, so this gives them structure and guidance, and eventually they’ll be able to do a lot of this stuff independently.
00:17:45.870
This is one that I am still working on—I haven't figured out the perfect balance yet, but I know it's important: junior developers need structure to thrive, especially at first. That means clear expectations and goals. You will not get fired if you do these things; it means assigned tasks, accountability, supervision, and regular feedback. I work at a flat organization with no managers, and we are terrible at structure. We just don't do it because, up until we started this program, we only hired mid-level to senior people who could be thrown in the deep end.
00:18:18.810
This just wasn’t going to work for people who were brand new to the field. We figured that out the hard way. Some of the best days in our program are our Wednesday half-days, where I group our apprentices in pairs of two to four. They get to build whatever they want within certain constraints. I say, 'Okay, your app has to cover these three things we learned this week; other than that, go wild.' I see the most creativity, collaboration, and excitement.
00:18:53.590
They usually are at home messaging me at 10:30 that night, still working on the things they built that day because it's theirs. That degree of freedom accelerates learning and increases motivation and enthusiasm. Giving a person time to work on an independent project can significantly build their skills and confidence, encouraging them to explore things you wouldn't have thought to teach them.
00:19:31.820
Positive feedback is crucial; it used to be one big slide all by itself, but it's not anymore because it often gets overlooked in the educational process. Positive feedback tends to get lost in the shuffle because we’re so focused on growth and improvement, but saying to somebody, 'You did a good job; that was great,' builds confidence, improves collaboration, and enhances team relationships.
00:20:12.620
Our CEO is one of the best business people I’ve ever met, but he’s not super touchy-feely. When he sends me an email, which he now does because he knows it motivates me, saying, 'Hey, you killed it in that meeting,' I keep that in my inbox, and I look at it a few times a day. Positive feedback, when it is specific, timely, and tied to performance, is incredibly powerful.
00:20:44.940
There is a flip side, though. A couple of my junior developers went to work on a client site with a project manager who thought they were amazing—because they really are! However, every day she came in, rained candy on their desks, and told them how great they were. I’m not exaggerating—every single day! They loved it for about two weeks, but after two months, they were just completely over it because the constant praise felt meaningless—it wasn’t tied to anything they had actually done.
00:21:40.380
Positive feedback loses its impact when it is nonspecific, insincere, or unrelated to actual performance. It should be specific, timely, and sincere. Growth feedback is something I came up with in the shower. I originally called it negative feedback, then changed it to constructive feedback, which still didn’t feel quite right, so now I call it growth feedback. The reason for this change is that I asked a group of developers how they felt when I said the word feedback. Their responses included 'stressed out,' 'nervous,' 'defensive,' and my favorite: 'horrified.'
