 I'm glad this is working. My name is Bree Thomas, I'm a covering marketer, just a little bit about my background. I've been clean for about two years now. Really, it was a great career, as great a career as it can be working in the dark arts. Loved it. In making the switch from marketer to developer, I attended a very intense coding camp for about six months. And I've been employed as a formal developer for just about over a year and a half. I work with Modset. We are a development firm and product consultancy based in Denver. I'm the only one on the team with less than 13 years experience. I'm also the only girl. And that is often pretty intimidating. But I do count myself very, very lucky to be working with what I consider to be masters of the craft. So I count myself very lucky. I also ran the Denver chapter for girl development. And so we work to bring professional level software education to women, judgment free. And I promise this is the last logo slide. You'll see. Old habits do die hard. So the subjects of developer growth and new developer training, apprenticeships, it's very near and dear to my heart. And so that's what I want to talk about today. I want to talk about apprenticeships and that in specifically in our industry, I find them to be a little on the scary side, quite frankly. And not just for apprentices, but also for employers. And so I'm going to talk about what's scary, what I think is missing, and what's important in developer apprenticeships. How should we be looking to value our apprentices and how should we be looking to value our programs and structure them? But before we get into that, a little on the inspiration for this talk. Because also near and dear to my heart are 80s, films. And so Burn Rubber does not mean warp speed is actually a line from an 80s cult classic called The Lost Boys. And I'd like to share just a two minute clip, the relevant portion of that movie with you now. Shut up. We are ravaging the base of the enemy. It's not our fault. They pulled the mind scramble on us. They opened the eyes of time. I'll drive. We don't ride with vampires. Fine. Stay here. We do now. Yeah. So not to come across as overly dramatic, I mean, I don't think that developer apprenticeships are nearly as scary as blood sucking vampires, although I guess it depends on who you're talking to. I love the scene in this movie because here's this kid Sam trying to save his brother, right? From a gang of vampires. He's got the impending deadline of nightfall upon him. He's got the frog brother screaming at him to hurry up, get out of here. Life depends on it. And they jump in the car and he damn near drives them all off a cliff to the certain death that they're trying so hard to avoid. And in that moment, that oh shit moment, he says, you know, burn rubber does not mean warp speed. Like, hey dudes, I'm going to get you out of here. But it's warp speed. It's not necessarily my tempo nor is it necessarily in the best interest of saving all of our asses right now. And so I like this kind of cheeky funny movie line and I like to kind of apply it as a valuable mantra in that working hard and being passionate, being committed, those things don't necessarily automatically add up to your ability to move at a predetermined speed. And that speed itself is not necessarily a prime indicator of progress or success or in extreme cases survival. However, in my developer training program and through my apprenticeships and I was in two of them post grad, I found myself supremely focused on how fast I was going. Was I coding fast enough? Was I learning fast enough? Oh my God, what happens if I don't know all the things by the deadline? What happens if I just don't know all the things? Maybe I'm not cut out to be a developer. And so thinking about this, this was a high degree of anxiety for me for a long time. To the tune of about 10 months. And I still sometimes will struggle with it. I have finally chilled out quite a bit from where I used to be. And how I did that is that there are a couple pieces, one, I took comfort in the value that I could bring to my team outside of hard coding skills. And that was really important for me. And then another way is that I just, I just got, I was a little bit easier on myself about learning and sort of the things that I needed to do to relieve pressure on myself to constantly be performing at a level that maybe I wasn't ready for. And to rather just focus on the learning and was I progressing. But that was a hard road to get to. And it was often wrought with moments of feeling like I can't even talk to my team about this. I don't even want to say anything. Sometimes I was met with an inability to even write any code. It was paralyzing in some ways. So I started the conversation with fellow developers and some students that I had gone to school with. And really started looking at apprenticeships in general in our industry. And so to get that conversation moving, I had to do a little bit of research. Research on historical apprenticeships, right? And so a historical apprenticeship is just simply, sorry about that, one sec. Let me get my notes up. Thank you. It's just a system to train on the job training any sort of new person in a particular trade. And this training often incorporates book reading, a little bit of schooling class, but most of it is on the job training. And historical apprenticeships began in the Middle Ages and they had some very specific levels associated with them. The first of which was just being an apprentice. And so apprentices, this was something that lasted for about seven years. And an apprentice would join a particular trade and they were compensated such that they didn't have to really worry about where their next meal was coming from. They weren't necessarily overpaid. They lived decently well enough and they just worked under a particular master craftsman for about seven years learning the trade. After that, an apprentice became, whoops, a journeyman. And a journeyman was this period of about three years where you could travel around and learn from other masters in the same trade. Just picking up sort of, you know, different approaches and what have you. And at the end of your journeyman phase, you were then eligible to apply for master. And so in being a master, you had to produce a sum of money and you had to fill out an application and you had to apply to the specific guild that you were trying to enter, okay? And this never took place back in the Middle Ages anyway prior to roughly about ten years. So a very long time. And I chose this slide for master because I think that, at least what I think, is that once you can drink and smoke at the same time while practicing your craft, you have arrived at master. I haven't arrived there yet. I do work with some people who are very adept at cocktailing and coding. I aspire, I do. So let's talk about some modern apprenticeships that we're probably all a little familiar with, right? Let's take doctors. Who out here can tell me how long the apprenticeship period is for a doctor? Just shout it out. Two years I hear. Five. Three to eight years. Probably depends on what kind of doctor you're looking at being. How about for electricians? One year? Three to, or four years for electricians. Four years. How about traditional engineers? Three to five years. I got one more for you. Don't mess this up. Tattoo artists. God, that's a great guess. Totally wrong, but good guess. All right, one to five years. One to five years for a tattoo artist. So here are some key takeaways for me, right, as I was reading about apprenticeships. And I think the first is pretty obvious. They take years, years, and they are methodical, right? There are these very specific transitions, and there are these requirements before even achieving the title of master. And that there's a commitment on both sides of that equation, right? Both employer and apprentice, they are very invested in this time. So what's so scary about developer apprenticeships? Well, I have to start with speed. I have to start with speed because if you look, I think it originates in a lot of the modern developer training programs because everywhere you look today there are tons of programs exploding everywhere, purporting to train you in as little as 24 hours or 10 weeks or three months or six months. And I think that then when you look at apprenticeships, they're actually not that far off from the training programs. Most apprenticeships that I found and was looking into were at three months, six months I found like very few that were at one year for a formal apprenticeship with a development team. And the concern about this is that I think that this sort of quick timing on these things, it sends a message that becoming a developer is fast. And if it's fast, it's easy. And if it's fast and easy, well, it's probably kind of just a finite endeavor, right? Let me just check that box off the list. I learned that. Now let me go collect my paycheck. Get started working. And we as developers, we know that what we do is not trivial. This shit is hard. And it's infinite, right? You're constantly learning. Things are constantly changing. And that becoming a good developer requires a passionate commitment, patience, conviction. Sometimes maybe you've got to be a little crazy. So another scary thing that I think exists in developer apprenticeships is assumptions. And I might have slight flare for the dramatic because if you listen to, if you read anything of David Brin, he will tell you that science fiction author, he will tell you that assumptions can lead to fatalities. So I don't think that any of the assumptions I'm going to present you with today in our industry around apprenticeships have actually led to anyone's death, but I do think that they're important and they often get overlooked. So assumptions by employers. Some scary assumptions by employers. The first one I would say is that employers assume apprentices will always be vocal and open, which is not always true. In fact, that's probably rarely the case. Another assumption is that by virtue that an employer will make is that by virtue of being a senior developer, you are well equipped to teach a junior developer. That's not always true either. And then there's a couple of assumptions that I think are key that are made by apprentices. The first would be that upon graduation from a modern development training program, regardless of whether it was 24 hours, 10 weeks or seven months, whatever the case, you are immediately employable and handsomely compensated. And most importantly, you are not an apprentice. I think another assumption made by apprentices is that the road from student to senior developer is a road that is paved with very distinct and well-defined levels and transitions that are easily portable from one job to the next. And so while we may not agree with David Brin and the severity of assumptions, I think that we can all agree that when assumptions are left unchecked and not discussed, that they can lead to some negative and unintended consequences. Measurement. So in and of itself, measurement, not a scary thing. But here are a few things about measurement, especially around apprenticeship programs that I do think is a little scary. I think a one-size-fits-all is a dangerous trap to fall into, whereby you create one very specific, fully laid out plan for an apprenticeship program, and then you expect that every apprentice who comes through will absolutely perform and succeed on that to the same expectation as you drafted it. And so every apprentice, every individual that comes in is going to have a different learning style, and they're going to have different strengths and weaknesses, and they're going to need to engage with you differently throughout the program. Also scary in measurement is limiting how you value an apprentice. So hard coding skills are absolutely important, but they're not the only thing to consider. Some other questions to ask is, can they integrate with your team effectively? Do we like them? Do they like us? Are they even happy when they come into work every day? And how would you know? And also, do they have other skills of interest? Are there other things that they can bring to the table? So take me, for instance, I brought marketing, client relations, even a little bit of legal expertise from my background, way, way back. And all of that ended up proving as value add in our business relationships. Follow through. This is probably, I think, just the most scary thing in talking with a lot of other former students who are apprentices now or who have gone through apprenticeship programs. And this is when we say, you find yourself in an apprenticeship program and you say, we're going to measure all of these things. We're going to check in and we're going to evaluate your progress as we move through. And then it doesn't happen. And this actually happens a lot. And I think it's just, you know, sort of the best laid plans, right? Of mice and men often go awry and that really what happens is work happens. And so your apprentice either starts producing great work and you're so busy that you're like, ah, they're working and apprenticeship is just on the job training. Just let them keep going. I'm not going to worry about it, right? It's just work happens. Things get busy and the apprenticeship evaluations often get pushed to the side and it's great that they're producing work and maybe great they're, you know, producing lots of billable work for you. But now what you've lost is a platform from which both of you to objectively and substantively look at where an apprentice is doing well, where you as an employer are doing well in the program and where you can find places to change and improve. So again, what's so scary about developer apprenticeships? Failing to recognize, identify, address assumptions, shotgunning them out like fast food. That's dangerous and neglecting to measure the right thing at the right time. So what's missing from apprenticeships in our industry? Profession versus skill. So many a developer training program can give a lot of students great skill, but it doesn't really teach them the business of building software. It doesn't necessarily all always help them integrate with a team dynamic and handling cross functional, you know, requirements between different members of a team. So you have to really look at training your apprentices around what it means to be in the business of building software, not just what their code looks like. Also growing up fast. So we're missing the time to just be an apprentice because of pressures of billability, because of pressures of, you know, feature releases, whatever the case may be, and the fact that an employer is making an investment. Often the time to be an apprentice, it just gets cut short. Teacher training. Again, if you are a senior developer, maybe you're great at teaching and if you're a senior developer who has an apprentice, maybe you need a little bit of help because just because you can set out a list of requirements doesn't mean you're well equipped to structure an actual curriculum and a curriculum that is molded to individual needs of different students. So what's missing from apprenticeships in our industry? A mindset. A mindset that a career and development is more than just a job slinging code. And the time to just be an apprentice and investing in mentors as formal teachers. So what's important? A couple of important things in developer apprenticeships that I think are key. Two ways street, meaning that self-directed learning can't be the only thing anymore. Of course, the expectation is there for apprentices to want to, you know, learn on their own, study at night, whatever the case may be, but that can't be the only thing. You can't just leave the burden of the apprenticeship program up to the apprentice. And that happens in a lot of situations because again, you get busy with work. And so it's important for the apprentice to feel valued and that the employer cares about the program, which means the employer needs to be an advocate of protecting that time and following through with measurement. Also important in, oops, sorry, is time. Again, because burn rubber does not mean warp speed. So I spoke with a lot of developers and apprentices when I was working on this talk and I asked just out of curiosity, did anyone think that you could reach senior developer status in one year? And the resulting answer was an emphatic no. As in like hell no. And that many wouldn't even consider a senior level designation for two or even three years. And so why is that? Because there's just no substitute for experience. Consider Malcolm Gladwell's outliers, right? And that all of the most successful musicians and athletes, they all had one thing in common and it wasn't an innate talent, it was the fact that they spent a lot of time in deliberate practice over and over and over again and by time to the tune of 10,000 hours or 10 years. And so consider apprenticeships that we talked about from the Middle Ages, lasting seven years and then three years as a journeyman before they were even eligible to apply for master status. And then consider just some of the modern apprenticeships we talked about now, today, right, tattoo artist, up to five years. Developer apprenticeships, even if you tack on the developer training program time, are lucky to hit one year. And I think that's pretty scary. So what is it about the length of time that's so important? Why, why so long? Because if I'm an apprentice, why would I bother to take a longer apprenticeship that an employer was offering over say a shorter one? I mean, surely I want to get to that title in that bump in salary sooner rather than later. And if I'm an employer, you know, why would I invest in a longer time? Why would I do that years instead of just three months or six months? How could I justify an investment of that size? I think it comes down to that, you know, learning to play the notes for an instrument is not the same as being a musician. Learning to play is really the first and arguably smaller hurdle and that applying the skill over and over and over again, this is what makes the difference between one who can play an instrument and one who can actually make music. And so the intangible elements of like communicating a vibe and a feeling and riffing off something else and, you know, making new innovations out of an old song, that's the mark of a great musician. And it's a business relationship between employer and apprentice, but the common goal should be about building a better developer. We want developers who can exercise autonomy, so we got to teach them how to think and we want developers who can integrate seamlessly within any team. We want a developer who can stretch beyond just the task itself and exhibit some thought leadership, a creative developer, someone capable of solving the problem and vision in what the system and the vision in what the, you know, finish line is going to look like and how to get there. And so the apprentice who becomes this developer is a valuable asset indeed and the employer who puts in the time and effort to foster this kind of apprentice. Well, I think they're pretty well positioned to retain that person for the long haul and that is definitely investment worth making. Skip to the next slide. Okay, sorry, running out of time. I skipped a few slides here and I'm going to get right to the bright ideas. Okay, so I talked a little bit about what's missing, what's important, and what's scary about developer apprenticeships, but I promised you a few ideas. So some of these are a little radical, but hopefully they'll spark some ideas for you guys as you're looking at your own apprenticeship programs within your respective companies. The first idea is to start it to and what I mean by that is when you're looking to hire an apprentice and you're developing a program, structure it for two years, structure it for two years and give that person the title of apprentice, pay them well, you want them focused on the work, not whether or not they can pay the electric bill that month, but you don't have to pay them obnoxiously. And if they're doing well and you want to give them a bump in salary, great, but don't change their title for the first two years and then give them at the end of two years the opportunity, depending on how they've performed, to either reapply for further apprenticeship or to move into whatever the role is that you've defined as a junior developer or whatever title you've given them, but as they move into that role with the understanding that they're going to work for you for one year as owed labor after the apprenticeship. So what I'm really saying is start it to but contract with them for three years, have some job security on both sides of the fence and an understanding that like, hey, we're in this for the long haul with you and this is what it looks like. Another idea is just product ties. Okay. So when you're hiring senior developers on your team, make sure that they understand the apprenticeship program within your company. It's a product. It's a product that the entire team has to foster and grow. And the expectation is that it is worked into the workflow just like anything else that they're doing, but make sure they have time to do that. Make sure that when you hire someone that when you set that expectation that they have the time to mentor the apprentices. Another good idea I think is pedagogy consulting. So there are plenty of teachers who have their summers off and I'm sure they would love to be paid at maybe a consultant rate and hire a teacher to come in and spend a little bit of time talking to you about your apprenticeship program and ways in which you can look to structure curriculum for the long term. And then the notion of an internal journeyman. So whatever size your team is and whether you're a product company or a consultancy. Embrace the idea that your apprentice shouldn't just be head down writing code all the time. Try to expose them to other teams. If you're a consultancy bring them to new biz meetings. Let them start to get an understanding of the entire business at hand and find a little bit out about what skill sets they might be bringing to the table that you didn't consider that can help you in other areas because when you have an apprentice who feels valued it makes a huge difference in their performance where you really need it to make a difference all learning how to write more advanced code. OK that's it.