Burn Rubber Does Not Mean Warp Speed
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Thomas, Bree
We talk about bringing new developers "up to speed quickly." Imposter syndrome is bad enough, but often junior developers feel pressured to learn faster and produce more. Developers often focus on velocity as the critical measure of success. The need for speed actually amplifies insecurities, magnifies imposter syndrome, and hinders growth. Instead let's talk about how we can track and plan progress using meaningful goals and metrics.
 Hi, my name is Bree Thomas and I'm going to go ahead and get started, obviously. I'm really happy to be here today. I haven't been to Atlanta in a very long time. I haven't been to Atlanta since I was a kid and my parents shipped me away for a summer to go and work on my grandfather's chicken farm. So standing here on this stage right now with all of you out there is a lot better than the chicken farm. Lot better. So a little bit about my professional background. I am a recovering marketer. I was in marketing and branding for 10 years. I've been clean for almost two years. Very proud of that. In deciding to make that career switch, I attended a six month super intensive developer training program and I have been formally employed as a real live developer for almost a year. Well, just over a year. I work here, mode said, we're a product consultancy and development firm based in Denver. I am the only one on the team with less than 13 years experience. I'm also the only girl on the team. And while that may sound daunting, some days it is, they are an extremely supportive team and I count myself extraordinarily lucky to be learning from masters of the craft. I also run the Denver chapter for girl development, helping to bring affordable, judgment free professional software education to women. And I really enjoy that. I swear this is the last logo slide. Some habits do die hard. I've been in exactly two apprenticeships since I graduated from the training program. And so as a newb, the subject of developer training and growth is very near and dear to my heart. But I find apprenticeships in our industry to be a little on the scary side, quite frankly, and not just for the apprentice. And that's what I want to talk about today. Specifically what is so scary about developer apprenticeships, what's missing from them, and at the end of the day, what's important? What should we value in our apprentices and our apprenticeship programs? My hope is that you'll leave here today with maybe some fresh perspective and a few ideas. But first, I'm going to take it back a little bit and talk about the inspiration for this talk. Because also near and dear to my heart are 80s movies. And the title, Burn Rubber Does Not Mean Warp Speed, was inspired by an 80s cult classic, The Lost Boys. And so I just wanted to take one minute of our time and share that relevant scene with you. So with that, I'm going to see you. We blew it down and we locked it. Shut up! We are wrapped in the face of the enemy. It's not our fault. They pull the mines down to us. They open their eyes and talk. I'll try. We don't ride with vampires. Fine. Stay here. We do now? Yeah. Come on. Get down. Let's get at it. Burn rubber. Yeah! Christ! Burn rubber does not mean war of speed. Okay. I certainly don't want to come across as overly dramatic. I mean, developer apprenticeships are not as scary as blood-sucking vampires. Guess it depends on who you ask. I love this scene in the movie because here's this kid, Sam, trying to save his brother and his friends, his family from a gang of vampires. He's got the impending deadline of nightfall upon him. The Frog Brothers are screaming at him to hurry up. And not to mention, he just saw a pack of vampires, like, for real. And as if that wasn't enough already, he damn near drives the whole lot of them off the edge of a cliff to the certain death that he's trying so hard to avoid. And it's in that edge of the cliff, oh, shit, moment, that he screams, burn rubber does not mean warp speed. Like, hey, dudes, I'm going to get us out of here. But warp speed is not necessarily my tempo and clearly not necessarily in the best interest of saving all our asses right now. And so I like to apply this cheeky movie line as kind of a valuable mantra and metaphor in that working hard, being passionate, and being committed, or being scared shitless for that matter, do not necessarily add up to an ability to move at a predetermined speed. And that speed is not necessarily the prime indicator of progress or success, or in the extreme case, survival. And yet, while I was learning to code in my developer training program, and as well as through both of my apprenticeships, I found myself supremely focused on how fast I was moving. 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? Oh, my God, what happens if I don't know all the things? Does that mean I'm not cut out to be a developer? And so it took about 10 months post-grad developer training program for me to chill out on some of that anxiety. Mind you, this is not because I am now a coding sensei. But because I found comfort in the value that I was able to bring outside of my hard coding skills. So I have a background in marketing, law, and client management. And I was able to contribute in a lot of areas both inside and outside of the code itself. Additionally, I found peace with myself in the rate at which I was learning, and the things that I needed to do as an individual to foster that learning. It was a really tough road getting to that spot, often wrought with doubt, and sometimes a crippling fear to even write more code, or even speak up about what I was thinking and what I was feeling. And so it was this journey, kind of the self-realization over the last year, that made me want to reflect and talk to my teammates and some other apprentices about how developer apprenticeships are perceived, how they're structured, how they're managed, and whether or not we as an industry might be missing some key opportunities to approve apprenticeships. So to get that conversation started, I did a little bit of research. So an apprenticeship is the system of training a new generation of practitioners of a trade or profession. Within on-the-job training approach, usually mixed with some kind of formal study, meaning book study, classroom study, and traditionally apprenticeships would also lead to the procurement of say a license in a regulated profession. And it's a system by which a lot of apprentices will launch their careers, as most of the training is done while working for an employer who invests in the impretist in exchange for continued labor, for an agreed upon amount of time after the apprentice has achieved competencies that were defined in the program. So the system was first developed in the later Middle Ages, and it came to be supervised by craft guilds and town governments. During this time, a typical apprentice was a fairly inexpensive form of labor, right, so whereby the master craftsmen would employ the apprentice in exchange for food, lodging, and formal training in the craft. And within the entirety of the apprenticeship system, there were some very specific stages and roles. The first obvious being that of an apprentice. In the Middle Ages, an apprentice spent about seven years in this phase. Apprentices were compensated such that they could live reasonably well, so they weren't worried about where my next meal is coming from. But certainly part of their compensation was the tutelage in the profession. And so, you know, they weren't rolling in the dough, so to speak. Following the apprentice years, one would advance to journeyman years. A journeyman is an individual who has completed an apprenticeship, and they are fully educated in a trade or craft. But they're not yet a master. So in the Middle Ages, journeymen were often required to accomplish a three-year working trip. Traveling around, gaining experience in the profession, across a variety of locations, working with different masters. This phase could actually last anywhere from three years to life, because, well, the final phase of master was never a guarantee. To become a master, a journeyman has to submit a master work to a guild for evaluation, and then they had to be admitted to the guild as a master. A master craftsman or master tradesman was a member of a guild, and in the European guild system, only masters and journeymen were allowed to actually be members of the guild. An aspiring master would have to pass through the career chain from apprentice to journeyman before he could be elected to become a master craftsman. Then, the journeyman would have to produce a sum of money and a master piece before they could actually gain that membership master within the guild. And if the master piece was not accepted by the masters, they could possibly remain a journeyman for the rest of their life. Also, I chose this picture because I think that you know when you have arrived at master when you can drink and smoke while executing your craft. I work with developers who can cocktail and code. I have not yet arrived. So, delving into the history of apprenticeships got me thinking about some familiar modern apprenticeships, and the length of their apprenticeship periods. So, the current Wiki definition cites modern apprenticeships as running somewhere between three to six years on average. So, let's consider some that we're probably all pretty familiar. Who can tell me how long the apprenticeship is for doctors? Just shout it out, people. Seven. Three to eight years. I guess it depends on what kind of doctor you are. What about electricians? Oh, four years. How about traditional engineers? Anyone? Bueller. No, three to five years. Marty's so excited over there. Three to five years. Okay, last one. Tattoo artist. Don't fail me now. Seven years. Wow, that's a good guess. It's not. It's one to five years. Okay. So, key takeaways for me as I was reading about apprenticeships is that they take years, like a lot of years, and they're methodical. Okay, there are stages, there are levels, hours requirements, and then an application for master status and licensing. And also that there's a commitment on both sides of the equation to that time in process, including committed in owed time after the formal apprenticeship period. So if we circle back to developer apprenticeships and what's so scary about them, I have to start with speed. I think the apprenticeships in our industry are pretty scary. I think the speed is what's so scary, and it originates in many of the modern developer training programs, which are growing at a prolific rate. Everywhere you look today, there are more books, online programs, schools, boot camps, all purporting to turn you into a developer fast, fast, fast. Like to the tune of 24 hours, 10 weeks, three months, six months, and also frightening is that unlike doctors, engineers, electricians, there's no licensing body, no regulations or standards for the quality of curriculum or the quality of students that these programs are producing. And now let's consider formal developer apprenticeships post-grad. Three months, six months, if you're lucky, you'll find one that's a year. The vast majority are running at three to six months, very few at a year longer, and even more terrifying is that the number of apprenticeships is actually pretty limited. Tons of employers are hiring graduates as fully qualified developers right out of the gate from some of these programs. And so here's what's concerning to me with the speed in this particular context. I think it promotes some dangerous misconceptions about our craft. Like learning to code is fast and fast is easy. And because it's fast and easy, well, then it is clearly a finite endeavor. Just something that you can check off the list and go start collecting a check. But as developers, we know that what we do is not trivial. The shit is hard. The learning is infinite and the mastery takes years, like to the tune of 10. And devoting your life to building great software requires a passionate commitment, patience, and conviction. Another scary thing about developer apprenticeships, I think, are assumptions. David Brinn, scientist in science fiction author said, the worst mistake of first contact made throughout history by individuals on both sides of every new encounter has been the unfortunate habit of making assumptions. It often proved fatal. Dun, dun, dun. Okay, so I might have a slight flair for the dramatic because I don't really believe that any of the assumptions I'm going to position with you right now have actually proved fatal, but I do think that they're important and I do think they get overlooked and they can result in unintended and negative consequences. A couple of assumptions made by employers. Employers assume apprentices will be vocal and open. And that is not always true, in fact, rarely. Also another assumption by employers, by virtue of being a senior developer, you are well equipped to teach a junior developer. Assumptions by apprentices. Upon graduation from a modern training program, you are immediately employable and handsomely compensated and most importantly, you are nothing like an apprentice. Another assumption, advancing through levels of developer status, apprentice if you happen to start there, or from junior level to senior level, for instance, are well defined transitions within our industry common throughout and easily portable as titles from one employer to the next. Left untreated, assumptions can be a very dangerous thing. Left untreated, they can position you in a pit that you find yourself having to dig out of. And that's kind of scary. So what are some potential consequences that we might find in this pit? Things like a young developer making the wrong choice in job because of a promise of a higher title and or salary and ending up in an environment where they're ultimately set up to fail. Or employer frustration because progress is not meeting expectations and they have zero input as to why that is. Confusion and anxiety on both sides of the fence about where and how an apprentice actually fits into the larger team. Another scary thing is measurement. Although in and of itself, measurement is not a scary thing, but specifically related to developer apprenticeships. Some things I think are scary are a one size fits all approach. So if we create a standard plan and very specific milestones and very specific skill set bars on a very specific timeline, and then we expect each apprentice to exist to succeed on the plan precisely as it was written, we're likely to find some disappointment. Because each apprentice is going to be different. And each one will have a different learning style and they will bring a different set of strengths and weaknesses to the table. So be wary of inflexibility of a one size fits all approach in an apprenticeship program and mentorship style. Hard coding skills are of course important. But if it's the only thing we evaluate our apprentices by, then we're missing out on some other important factors. For instance, can they integrate with our team effectively? Do we like them? Gosh, do they even like us? Are they creative thinkers? Can we relate to them personally? Are they happy when they come into work every day? And how would you know? Additionally, let's consider other professional skills that apprentices can offer from their respective backgrounds. Take me for instance. So I bring marketing, client management, and even some legal expertise, which were a value add to the team outside of the code base and ended up being pretty critical in our business relationships. So when we consider the value of an apprentice, it's important to think beyond just the hard coding skills. Another scary thing where measurement and developer apprenticeships is concerned is follow through. When we say we're going to measure, but then we don't. And this actually happens a lot. It's typically a case of the best laid plans of mice and men often go awry, meaning at the start of the apprenticeship, it's met with a lot of energy about all the things that make up the program, like weekly check-ins and scheduled mentorship and individual projects and times to time to read and learn and explore. And then work happens. Or the apprentice just begins producing and quickly the team loses sight of the apprenticeship because now they have someone producing real work. So let's just keep them. Let them do that because everyone is so busy in any way. Really what's the point and apprenticeship is just on the job training, right? But now both employer and apprentice have lost a platform from which to objectively and substantively evaluate progress, contributions, and growth. So what's so scary about developer apprenticeships? Shotgunning apprentices out the door like fast food. Failing to recognize, identify, and address assumptions on both sides of the fence. And neglecting to measure the right things at the right time on the right scale. So what's missing from the apprenticeships in our industry? The mindset of learning a profession versus learning a skill. Many a developer training program can give people some skills. But becoming a successful developer is about learning the profession. And not just with the mindset of trying to bulk up coding skills as quickly as possible, but rather taking the time to mentor apprentices around things like interpersonal skills, your cross functional team dynamics, and mentoring them around getting a deep understanding of the business of building software. We're also missing the time to just be an apprentice. Pressures of billability, they're real, whether you're a product company or a consultancy. But also real is the investment that you're making in an apprentice. And because of these pressures, the time to just be an apprentice is in jeopardy of being cut short. The demand for developers is high. The junior salary rates and title expectations, many would absolutely say are inflated. Employers and apprentices both are looking for some degree of job security. And yet so few apprenticeships are structured for any kind of long term commitment. Much like we might structure a relocation package, we should look for mutually beneficial ways in which to structure longer term commitments between the parties of an apprenticeship. You know, a promise for something longer than six months. It'll put both sides in a position to focus on what's important in the program, as well as providing for some predictability on the return that the employer is making. Another important ingredient, investing in mentors as teachers. So just because we have a team of seniors, doesn't mean we have a team of teachers. And just because we can make a list of all the skills needed to be a fully functioning member of our team, doesn't mean we can effectively structure a curriculum appropriately tailored to the individual to achieve that set of requirements. Teaching as a formal skill set is missing from some apprenticeships. We should be looking for ways to invest in our mentors as teachers, to give them the ideas and the requisite skills to foster really great apprentices. So what's missing from the apprenticeships? The mindset that programming is more than just slinging code. The time to just be an apprentice and investing in mentors as formal teachers. What's important in developer apprenticeships? We all know that software development is better served with an agile approach instead of a waterfall approach. Our apprenticeship programs are better served as well. Approach the program like you would approach developing a new product. Start with your key stakeholders, mentors and apprentice. Discuss the goals. What are going to be the measures of success? What are the risks? Align on all the most important aspects of the program with a very clear understanding of each person's role in that construct. A mutual and well understood commitment to those goals is critical for success. Also critical for success is diligence in the process. So rigorously implement and adhere to iteration planning meetings. At each one, talk about what went well, what fell short of the goals, and then figure out why and how and fix it. And have a backlog and groom that backlog because over time, as the team gains insight into an apprentice's specific strengths and weaknesses, now you can adjust the tutelage and the expectations and you can make sure it's reflected in the backlog. Retrospectives. Quite simply, do them. Use the time to be honest and frank with the team about mentor and mentee pairings. Maybe some are not working well because of particular learning styles. Maybe an apprentice needs more rotation or less rotation among mentors on your team. Use retrospectives as a place for mentors and apprentices to address assumptions, address issues and expectations. And then make some critical decisions that protect the goals of the apprentice, the goals of the employer, and the goals of the program. Also important is a two-way street because self-directed learning, it can't be the only thing anymore. The industry moves fast. The demand for top-notch developers is growing exponentially. The expectation of the apprentice should absolutely include self-directed study. An apprentice should exhibit a desire to immerse themselves in the learning and work hard. But the burden of keeping the apprenticeship on track can't just fall on the apprentice. The apprentice needs to know that the apprenticeship is equally important to the employer. An apprentice generally lacks a deep grasp on their importance to the business. And this is really unfortunate because when an apprentice feels valued in their role, it has a very positive influence on their performance in the program. An apprentice needs to see an employer's commitment to the construct, and they need to feel like the employer is an advocate in that apprenticeship. That the learning investment isn't just important as the apprentice is just as important as the apprentice becoming billable and moving into that role of developer. Holistic value is important. So again, measuring the whole apprentice, it's important not just for the employer, but to help that apprentice gain confidence as they're working to bring up their coding skills. For me personally, being able to contribute to the team in other ways was a huge benefit in easing some of my code skill anxiety. And it was also critical in moving my focus from one of, oh my gosh, how fast am I going to, okay, am I doing what I need to do to continue progressing? So remember to consider everything that makes up the value of an apprentice. Coding skills, creative problem solving, personality. And last, but definitely not least, important in developer apprenticeships is time. Because burn rubber does not mean warp speed. I spoke with a lot of developers and apprentices as I was working on this talk, and I asked them just out of curiosity if they thought it was possible to reach senior developer status at one year. And all of them gave me an emphatic no. And all of them said they wouldn't even consider someone a senior close to that, maybe not even for two or three years, many said a lot more than that. And why is that? Because there is no substitute for experience. Consider Malcolm Gladwell's Outliers, if you've read that, in that all the greatest athletes and musicians had one thing in common, and it wasn't an innate talent, but rather deliberate practice and enough time to get good, like to the tune of 10,000 hours or 10 years. And consider apprenticeships of the Middle Ages lasting seven years or plus three years in journeyman status before they're even eligible to apply as a master. And consider some of the modern apprenticeships that we talked about today, like doctors, electricians, even tattoo artists. They invest years in learning their trade and mastering those associated skills. Developer apprenticeships, even if we tack on the developer training program, are lucky to amount to one full year. But what is it really about the short versus long that's so important? Like if I'm an apprentice, why would I bother with a long apprenticeship over a short one? I mean, getting to that bump in title means a bump in salary. Why would I waste years if I could accomplish it in a matter of months? Conversely, if I'm an employer, why would I invest in the prospect of years over months? What's in it for me? How can I justify an investment of that size? I think because learning to play the notes for an instrument is not the same as being a musician. Learning to play is but the first and arguably the smaller hurdle. Applying that skill over and over and over again, gaining performance over time is what marks the difference between one who can play an instrument and one who can make music. The intangible elements of communicating a vibe, a feeling, or riffing something new off of an existing song, that's the mark of a great musician. And you need that runway. It's a business relationship between employer and apprentice. And the common goal should be one of building a better developer, a well-paid developer who can exercise autonomy and also integrate seamlessly within any team. A developer who stretches beyond just the task itself and exhibits thought leadership. A creative developer capable of applying a system's view in solving the problem and vision in what the finish line looks like and how to get there. And the apprentice who becomes this developer is a valuable asset. And right now, today, they can write their ticket almost anywhere. And the employer who fosters this kind of apprentice is well positioned to retain them for the long term, which is definitely worth the investment and certainly more economical. So what's important in developer apprenticeships? An agile approach and diligence in that application. The two-way street, put into what you want to get out and that doesn't just mean the apprentice. Holistic value, measure more than just the hard coding skills. And lastly, favor the marathon. We know you're coming a great developer. It's not a sprint. It's a marathon. So let's find ways in which to construct apprenticeships that are less about sprinting and more about a long-term commitment between teammates. So I've talked about what's scary, what's missing, what's important in developer apprenticeships. I hope that some of it was fresh perspective. But I also promised you some ideas. So here are a few thought starters that I brainstormed with my team and some of them strike you as too radical. Well, then I hope that they at least plan a seed of ideation as you think about creating or adding to some of your apprenticeship programs. Start at two, out of the gate. Structure your apprenticeships for two years. Pay the apprentice well, but you don't have to be obnoxious. If you want to give them a pay increase after six months or one year for whatever reason, great. Do it, but don't change their title. Keep them titled as an apprentice for two years with an option to reapply for continued apprenticeship after they complete the program. Or if you feel like they're ready, let them begin working off their owed labor of one year as a developer on your team. That's right. Start at two, but contract for three. Treat your apprenticeship program like a product. Integrate it into the fabric of your business and the team. And then after your team knows when they get hired with you, that mentoring is part of the job. And as such, you're going to give them the tools they need to be good at that job. And confersly, they're actually expected to help foster and improve that product over time. And I think this is really important. I think you need the team to take some ownership and realize accountability in the apprenticeship program for it to be successful. Hire a teacher to teach your senior mentors. Lots of teachers have their summers off. I'm sure they would love to make consultant rates to come in and do some workshops with your team. They don't have to be developers necessarily, but find someone who can help your team think about and structure a long term curriculum and evaluations to support that curriculum and to give you some pointers on how to engage with students of various learning styles. If you don't know any teachers, then reach out to a place like Turing. They know a thing or two about teaching students. The point being is don't underestimate the skill it takes to be good at teaching. And so seek advice and invest in that. Include the idea of a journeyman in your apprenticeship program, but focus it internally. So what I mean is have your apprentice travel around to various teams, even departments, especially departments if applicable at your company. Encourage the development of skills outside of just writing code. If you happen to be a large scale product company, lots of different development teams, give them time to bounce from team to team. Understand the varying dynamics and kind of figure out where maybe they would fit in best. And if you're a small consultancy, bring them to new business meetings. Include them in parts of the process that are not just about writing code, like design, research, testing. Because a well-rounded apprentice can become quite the valuable developer. Thank you. applause
 Hi, my name is Bree Thomas and I'm going to go ahead and get started, obviously.  I'm really happy to be here today.  I haven't been to Atlanta in a very long time.  I haven't been to Atlanta since I was a kid and my parents shipped me away for a summer  to go and work on my grandfather's chicken farm.  So standing here on this stage right now with all of you out there is a lot better than  the chicken farm.  Lot better.  So a little bit about my professional background.  I am a recovering marketer.  I was in marketing and branding for 10 years.  I've been clean for almost two years.  Very proud of that.  In deciding to make that career switch, I attended a six month super intensive developer  training program and I have been formally employed as a real live developer for almost  a year.  Well, just over a year.  I work here, mode said, we're a product consultancy and development firm based in Denver.  I am the only one on the team with less than 13 years experience.  I'm also the only girl on the team.  And while that may sound daunting, some days it is, they are an extremely supportive team  and I count myself extraordinarily lucky to be learning from masters of the craft.  I also run the Denver chapter for girl development, helping to bring affordable, judgment free  professional software education to women.  And I really enjoy that.  I swear this is the last logo slide.  Some habits do die hard.  I've been in exactly two apprenticeships since I graduated from the training program.  And so as a newb, the subject of developer training and growth is very near and dear  to my heart.  But I find apprenticeships in our industry to be a little on the scary side, quite frankly,  and not just for the apprentice.  And that's what I want to talk about today.  Specifically what is so scary about developer apprenticeships, what's missing from them,  and at the end of the day, what's important?  What should we value in our apprentices and our apprenticeship programs?  My hope is that you'll leave here today with maybe some fresh perspective and a few ideas.  But first, I'm going to take it back a little bit and talk about the inspiration for this  talk.  Because also near and dear to my heart are 80s movies.  And the title, Burn Rubber Does Not Mean Warp Speed, was inspired by an 80s cult classic,  The Lost Boys.  And so I just wanted to take one minute of our time and share that relevant scene with  you.  So with that, I'm going to see you.  We blew it down and we locked it.  Shut up!  We are wrapped in the face of the enemy.  It's not our fault. They pull the mines down to us.  They open their eyes and talk.  I'll try.  We don't ride with vampires.  Fine. Stay here.  We do now?  Yeah.  Come on. Get down. Let's get at it.  Burn rubber.  Yeah!  Christ!  Burn rubber does not mean war of speed.  Okay. I certainly don't want to come across as overly dramatic.  I mean, developer apprenticeships are not as scary as blood-sucking vampires.  Guess it depends on who you ask.  I love this scene in the movie because here's this kid, Sam,  trying to save his brother and his friends, his family from a gang of vampires.  He's got the impending deadline of nightfall upon him.  The Frog Brothers are screaming at him to hurry up.  And not to mention, he just saw a pack of vampires, like, for real.  And as if that wasn't enough already, he damn near drives the whole lot of them off the edge of a cliff  to the certain death that he's trying so hard to avoid.  And it's in that edge of the cliff, oh, shit, moment, that he screams,  burn rubber does not mean warp speed.  Like, hey, dudes, I'm going to get us out of here.  But warp speed is not necessarily my tempo and clearly not necessarily in the best interest of saving all our asses right now.  And so I like to apply this cheeky movie line as kind of a valuable mantra and metaphor  in that working hard, being passionate, and being committed, or being scared shitless for that matter,  do not necessarily add up to an ability to move at a predetermined speed.  And that speed is not necessarily the prime indicator of progress or success, or in the extreme case, survival.  And yet, while I was learning to code in my developer training program,  and as well as through both of my apprenticeships, I found myself supremely focused on how fast I was moving.  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?  Oh, my God, what happens if I don't know all the things?  Does that mean I'm not cut out to be a developer?  And so it took about 10 months post-grad developer training program for me to chill out on some of that anxiety.  Mind you, this is not because I am now a coding sensei.  But because I found comfort in the value that I was able to bring outside of my hard coding skills.  So I have a background in marketing, law, and client management.  And I was able to contribute in a lot of areas both inside and outside of the code itself.  Additionally, I found peace with myself in the rate at which I was learning,  and the things that I needed to do as an individual to foster that learning.  It was a really tough road getting to that spot, often wrought with doubt,  and sometimes a crippling fear to even write more code, or even speak up about what I was thinking and what I was feeling.  And so it was this journey, kind of the self-realization over the last year,  that made me want to reflect and talk to my teammates and some other apprentices  about how developer apprenticeships are perceived, how they're structured, how they're managed,  and whether or not we as an industry might be missing some key opportunities to approve apprenticeships.  So to get that conversation started, I did a little bit of research.  So an apprenticeship is the system of training a new generation of practitioners of a trade or profession.  Within on-the-job training approach, usually mixed with some kind of formal study,  meaning book study, classroom study, and traditionally apprenticeships  would also lead to the procurement of say a license in a regulated profession.  And it's a system by which a lot of apprentices will launch their careers,  as most of the training is done while working for an employer who invests in the impretist in exchange for continued labor,  for an agreed upon amount of time after the apprentice has achieved competencies that were defined in the program.  So the system was first developed in the later Middle Ages,  and it came to be supervised by craft guilds and town governments.  During this time, a typical apprentice was a fairly inexpensive form of labor, right,  so whereby the master craftsmen would employ the apprentice in exchange for food, lodging, and formal training in the craft.  And within the entirety of the apprenticeship system, there were some very specific stages and roles.  The first obvious being that of an apprentice.  In the Middle Ages, an apprentice spent about seven years in this phase.  Apprentices were compensated such that they could live reasonably well,  so they weren't worried about where my next meal is coming from.  But certainly part of their compensation was the tutelage in the profession.  And so, you know, they weren't rolling in the dough, so to speak.  Following the apprentice years, one would advance to journeyman years.  A journeyman is an individual who has completed an apprenticeship,  and they are fully educated in a trade or craft.  But they're not yet a master.  So in the Middle Ages, journeymen were often required to accomplish a three-year working trip.  Traveling around, gaining experience in the profession, across a variety of locations, working with different masters.  This phase could actually last anywhere from three years to life, because, well, the final phase of master was never a guarantee.  To become a master, a journeyman has to submit a master work to a guild for evaluation,  and then they had to be admitted to the guild as a master.  A master craftsman or master tradesman was a member of a guild,  and in the European guild system, only masters and journeymen were allowed to actually be members of the guild.  An aspiring master would have to pass through the career chain from apprentice to journeyman before he could be elected to become a master craftsman.  Then, the journeyman would have to produce a sum of money and a master piece before they could actually gain that membership master within the guild.  And if the master piece was not accepted by the masters, they could possibly remain a journeyman for the rest of their life.  Also, I chose this picture because I think that you know when you have arrived at master when you can drink and smoke while executing your craft.  I work with developers who can cocktail and code. I have not yet arrived.  So, delving into the history of apprenticeships got me thinking about some familiar modern apprenticeships,  and the length of their apprenticeship periods.  So, the current Wiki definition cites modern apprenticeships as running somewhere between three to six years on average.  So, let's consider some that we're probably all pretty familiar.  Who can tell me how long the apprenticeship is for doctors?  Just shout it out, people.  Seven.  Three to eight years. I guess it depends on what kind of doctor you are.  What about electricians?  Oh, four years.  How about traditional engineers?  Anyone?  Bueller.  No, three to five years.  Marty's so excited over there. Three to five years.  Okay, last one.  Tattoo artist.  Don't fail me now.  Seven years.  Wow, that's a good guess. It's not. It's one to five years.  Okay.  So, key takeaways for me as I was reading about apprenticeships is that they take years, like a lot of years,  and they're methodical.  Okay, there are stages, there are levels, hours requirements, and then an application for master status and licensing.  And also that there's a commitment on both sides of the equation to that time in process, including committed in owed time after the formal apprenticeship period.  So if we circle back to developer apprenticeships and what's so scary about them, I have to start with speed.  I think the apprenticeships in our industry are pretty scary.  I think the speed is what's so scary, and it originates in many of the modern developer training programs, which are growing at a prolific rate.  Everywhere you look today, there are more books, online programs, schools, boot camps, all purporting to turn you into a developer fast, fast, fast.  Like to the tune of 24 hours, 10 weeks, three months, six months, and also frightening is that unlike doctors, engineers, electricians, there's no licensing body,  no regulations or standards for the quality of curriculum or the quality of students that these programs are producing.  And now let's consider formal developer apprenticeships post-grad.  Three months, six months, if you're lucky, you'll find one that's a year.  The vast majority are running at three to six months, very few at a year longer, and even more terrifying is that the number of apprenticeships is actually pretty limited.  Tons of employers are hiring graduates as fully qualified developers right out of the gate from some of these programs.  And so here's what's concerning to me with the speed in this particular context.  I think it promotes some dangerous misconceptions about our craft.  Like learning to code is fast and fast is easy.  And because it's fast and easy, well, then it is clearly a finite endeavor.  Just something that you can check off the list and go start collecting a check.  But as developers, we know that what we do is not trivial.  The shit is hard.  The learning is infinite and the mastery takes years, like to the tune of 10.  And devoting your life to building great software requires a passionate commitment, patience, and conviction.  Another scary thing about developer apprenticeships, I think, are assumptions.  David Brinn, scientist in science fiction author said, the worst mistake of first contact made throughout history by individuals on both sides of every new encounter  has been the unfortunate habit of making assumptions.  It often proved fatal.  Dun, dun, dun.  Okay, so I might have a slight flair for the dramatic because I don't really believe that any of the assumptions I'm going to position with you right now  have actually proved fatal, but I do think that they're important and I do think they get overlooked and they can result in unintended and negative consequences.  A couple of assumptions made by employers.  Employers assume apprentices will be vocal and open.  And that is not always true, in fact, rarely.  Also another assumption by employers, by virtue of being a senior developer, you are well equipped to teach a junior developer.  Assumptions by apprentices.  Upon graduation from a modern training program, you are immediately employable and handsomely compensated and most importantly, you are nothing like an apprentice.  Another assumption, advancing through levels of developer status, apprentice if you happen to start there, or from junior level to senior level, for instance,  are well defined transitions within our industry common throughout and easily portable as titles from one employer to the next.  Left untreated, assumptions can be a very dangerous thing.  Left untreated, they can position you in a pit that you find yourself having to dig out of.  And that's kind of scary.  So what are some potential consequences that we might find in this pit?  Things like a young developer making the wrong choice in job because of a promise of a higher title and or salary and ending up in an environment where they're ultimately set up to fail.  Or employer frustration because progress is not meeting expectations and they have zero input as to why that is.  Confusion and anxiety on both sides of the fence about where and how an apprentice actually fits into the larger team.  Another scary thing is measurement.  Although in and of itself, measurement is not a scary thing, but specifically related to developer apprenticeships.  Some things I think are scary are a one size fits all approach.  So if we create a standard plan and very specific milestones and very specific skill set bars on a very specific timeline,  and then we expect each apprentice to exist to succeed on the plan precisely as it was written, we're likely to find some disappointment.  Because each apprentice is going to be different.  And each one will have a different learning style and they will bring a different set of strengths and weaknesses to the table.  So be wary of inflexibility of a one size fits all approach in an apprenticeship program and mentorship style.  Hard coding skills are of course important.  But if it's the only thing we evaluate our apprentices by, then we're missing out on some other important factors.  For instance, can they integrate with our team effectively?  Do we like them?  Gosh, do they even like us?  Are they creative thinkers?  Can we relate to them personally?  Are they happy when they come into work every day?  And how would you know?  Additionally, let's consider other professional skills that apprentices can offer from their respective backgrounds.  Take me for instance.  So I bring marketing, client management, and even some legal expertise,  which were a value add to the team outside of the code base and ended up being pretty critical in our business relationships.  So when we consider the value of an apprentice, it's important to think beyond just the hard coding skills.  Another scary thing where measurement and developer apprenticeships is concerned is follow through.  When we say we're going to measure, but then we don't.  And this actually happens a lot.  It's typically a case of the best laid plans of mice and men often go awry,  meaning at the start of the apprenticeship, it's met with a lot of energy about all the things that make up the program,  like weekly check-ins and scheduled mentorship and individual projects and times to time to read and learn and explore.  And then work happens.  Or the apprentice just begins producing and quickly the team loses sight of the apprenticeship because now they have someone producing real work.  So let's just keep them.  Let them do that because everyone is so busy in any way.  Really what's the point and apprenticeship is just on the job training, right?  But now both employer and apprentice have lost a platform from which to objectively and substantively evaluate progress, contributions, and growth.  So what's so scary about developer apprenticeships?  Shotgunning apprentices out the door like fast food.  Failing to recognize, identify, and address assumptions on both sides of the fence.  And neglecting to measure the right things at the right time on the right scale.  So what's missing from the apprenticeships in our industry?  The mindset of learning a profession versus learning a skill.  Many a developer training program can give people some skills.  But becoming a successful developer is about learning the profession.  And not just with the mindset of trying to bulk up coding skills as quickly as possible, but rather taking the time to mentor apprentices around things like interpersonal skills, your cross functional team dynamics,  and mentoring them around getting a deep understanding of the business of building software.  We're also missing the time to just be an apprentice.  Pressures of billability, they're real, whether you're a product company or a consultancy.  But also real is the investment that you're making in an apprentice.  And because of these pressures, the time to just be an apprentice is in jeopardy of being cut short.  The demand for developers is high.  The junior salary rates and title expectations, many would absolutely say are inflated.  Employers and apprentices both are looking for some degree of job security.  And yet so few apprenticeships are structured for any kind of long term commitment.  Much like we might structure a relocation package, we should look for mutually beneficial ways in which to structure longer term commitments between the parties of an apprenticeship.  You know, a promise for something longer than six months.  It'll put both sides in a position to focus on what's important in the program, as well as providing for some predictability on the return that the employer is making.  Another important ingredient, investing in mentors as teachers.  So just because we have a team of seniors, doesn't mean we have a team of teachers.  And just because we can make a list of all the skills needed to be a fully functioning member of our team,  doesn't mean we can effectively structure a curriculum appropriately tailored to the individual to achieve that set of requirements.  Teaching as a formal skill set is missing from some apprenticeships.  We should be looking for ways to invest in our mentors as teachers,  to give them the ideas and the requisite skills to foster really great apprentices.  So what's missing from the apprenticeships?  The mindset that programming is more than just slinging code.  The time to just be an apprentice and investing in mentors as formal teachers.  What's important in developer apprenticeships?  We all know that software development is better served with an agile approach instead of a waterfall approach.  Our apprenticeship programs are better served as well.  Approach the program like you would approach developing a new product.  Start with your key stakeholders, mentors and apprentice.  Discuss the goals.  What are going to be the measures of success?  What are the risks?  Align on all the most important aspects of the program with a very clear understanding of each person's role in that construct.  A mutual and well understood commitment to those goals is critical for success.  Also critical for success is diligence in the process.  So rigorously implement and adhere to iteration planning meetings.  At each one, talk about what went well, what fell short of the goals,  and then figure out why and how and fix it.  And have a backlog and groom that backlog because over time, as the team gains insight into an apprentice's specific strengths and weaknesses,  now you can adjust the tutelage and the expectations and you can make sure it's reflected in the backlog.  Retrospectives. Quite simply, do them.  Use the time to be honest and frank with the team about mentor and mentee pairings.  Maybe some are not working well because of particular learning styles.  Maybe an apprentice needs more rotation or less rotation among mentors on your team.  Use retrospectives as a place for mentors and apprentices to address assumptions, address issues and expectations.  And then make some critical decisions that protect the goals of the apprentice, the goals of the employer, and the goals of the program.  Also important is a two-way street because self-directed learning, it can't be the only thing anymore.  The industry moves fast. The demand for top-notch developers is growing exponentially.  The expectation of the apprentice should absolutely include self-directed study.  An apprentice should exhibit a desire to immerse themselves in the learning and work hard.  But the burden of keeping the apprenticeship on track can't just fall on the apprentice.  The apprentice needs to know that the apprenticeship is equally important to the employer.  An apprentice generally lacks a deep grasp on their importance to the business.  And this is really unfortunate because when an apprentice feels valued in their role,  it has a very positive influence on their performance in the program.  An apprentice needs to see an employer's commitment to the construct,  and they need to feel like the employer is an advocate in that apprenticeship.  That the learning investment isn't just important as the apprentice is just as important as the apprentice becoming billable and moving into that role of developer.  Holistic value is important.  So again, measuring the whole apprentice, it's important not just for the employer,  but to help that apprentice gain confidence as they're working to bring up their coding skills.  For me personally, being able to contribute to the team in other ways was a huge benefit in easing some of my code skill anxiety.  And it was also critical in moving my focus from one of, oh my gosh, how fast am I going to, okay,  am I doing what I need to do to continue progressing?  So remember to consider everything that makes up the value of an apprentice.  Coding skills, creative problem solving, personality.  And last, but definitely not least, important in developer apprenticeships is time.  Because burn rubber does not mean warp speed.  I spoke with a lot of developers and apprentices as I was working on this talk,  and I asked them just out of curiosity if they thought it was possible to reach senior developer status at one year.  And all of them gave me an emphatic no.  And all of them said they wouldn't even consider someone a senior close to that,  maybe not even for two or three years, many said a lot more than that.  And why is that?  Because there is no substitute for experience.  Consider Malcolm Gladwell's Outliers, if you've read that,  in that all the greatest athletes and musicians had one thing in common,  and it wasn't an innate talent, but rather deliberate practice and enough time to get good,  like to the tune of 10,000 hours or 10 years.  And consider apprenticeships of the Middle Ages lasting seven years or plus three years in journeyman status  before they're even eligible to apply as a master.  And consider some of the modern apprenticeships that we talked about today,  like doctors, electricians, even tattoo artists.  They invest years in learning their trade and mastering those associated skills.  Developer apprenticeships, even if we tack on the developer training program,  are lucky to amount to one full year.  But what is it really about the short versus long that's so important?  Like if I'm an apprentice, why would I bother with a long apprenticeship over a short one?  I mean, getting to that bump in title means a bump in salary.  Why would I waste years if I could accomplish it in a matter of months?  Conversely, if I'm an employer, why would I invest in the prospect of years over months?  What's in it for me?  How can I justify an investment of that size?  I think because learning to play the notes for an instrument is not the same as being a musician.  Learning to play is but the first and arguably the smaller hurdle.  Applying that skill over and over and over again,  gaining performance over time is what marks the difference between  one who can play an instrument and one who can make music.  The intangible elements of communicating a vibe, a feeling, or riffing something new off of an existing song,  that's the mark of a great musician.  And you need that runway.  It's a business relationship between employer and apprentice.  And the common goal should be one of building a better developer,  a well-paid developer who can exercise autonomy and also integrate seamlessly within any team.  A developer who stretches beyond just the task itself and exhibits thought leadership.  A creative developer capable of applying a system's view in solving the problem and vision in what the finish line looks like  and how to get there.  And the apprentice who becomes this developer is a valuable asset.  And right now, today, they can write their ticket almost anywhere.  And the employer who fosters this kind of apprentice is well positioned to retain them for the long term,  which is definitely worth the investment and certainly more economical.  So what's important in developer apprenticeships?  An agile approach and diligence in that application.  The two-way street, put into what you want to get out and that doesn't just mean the apprentice.  Holistic value, measure more than just the hard coding skills.  And lastly, favor the marathon.  We know you're coming a great developer.  It's not a sprint.  It's a marathon.  So let's find ways in which to construct apprenticeships that are less about sprinting  and more about a long-term commitment between teammates.  So I've talked about what's scary, what's missing, what's important in developer apprenticeships.  I hope that some of it was fresh perspective.  But I also promised you some ideas.  So here are a few thought starters that I brainstormed with my team  and some of them strike you as too radical.  Well, then I hope that they at least plan a seed of ideation  as you think about creating or adding to some of your apprenticeship programs.  Start at two, out of the gate.  Structure your apprenticeships for two years.  Pay the apprentice well, but you don't have to be obnoxious.  If you want to give them a pay increase after six months or one year for whatever reason, great.  Do it, but don't change their title.  Keep them titled as an apprentice for two years with an option to reapply for continued apprenticeship  after they complete the program.  Or if you feel like they're ready, let them begin working off their owed labor of one year as a developer on your team.  That's right.  Start at two, but contract for three.  Treat your apprenticeship program like a product.  Integrate it into the fabric of your business and the team.  And then after your team knows when they get hired with you, that mentoring is part of the job.  And as such, you're going to give them the tools they need to be good at that job.  And confersly, they're actually expected to help foster and improve that product over time.  And I think this is really important.  I think you need the team to take some ownership and realize accountability in the apprenticeship program for it to be successful.  Hire a teacher to teach your senior mentors.  Lots of teachers have their summers off.  I'm sure they would love to make consultant rates to come in and do some workshops with your team.  They don't have to be developers necessarily, but find someone who can help your team think about and structure a long term curriculum  and evaluations to support that curriculum and to give you some pointers on how to engage with students of various learning styles.  If you don't know any teachers, then reach out to a place like Turing.  They know a thing or two about teaching students.  The point being is don't underestimate the skill it takes to be good at teaching.  And so seek advice and invest in that.  Include the idea of a journeyman in your apprenticeship program, but focus it internally.  So what I mean is have your apprentice travel around to various teams, even departments, especially departments if applicable at your company.  Encourage the development of skills outside of just writing code.  If you happen to be a large scale product company, lots of different development teams, give them time to bounce from team to team.  Understand the varying dynamics and kind of figure out where maybe they would fit in best.  And if you're a small consultancy, bring them to new business meetings.  Include them in parts of the process that are not just about writing code, like design, research, testing.  Because a well-rounded apprentice can become quite the valuable developer.  Thank you.  applause
Burn_Rubber_Does_Not_Mean_Warp_Speed_0_47.png Burn_Rubber_Does_Not_Mean_Warp_Speed_48_155.png Burn_Rubber_Does_Not_Mean_Warp_Speed_156_299.png Burn_Rubber_Does_Not_Mean_Warp_Speed_300_1067.png Burn_Rubber_Does_Not_Mean_Warp_Speed_1068_1511.png Burn_Rubber_Does_Not_Mean_Warp_Speed_1512_1883.png Burn_Rubber_Does_Not_Mean_Warp_Speed_1884_3683.png Burn_Rubber_Does_Not_Mean_Warp_Speed_3684_4715.png Burn_Rubber_Does_Not_Mean_Warp_Speed_4716_5123.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5124_5183.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5184_5231.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5232_5291.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5292_5339.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5340_5483.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5484_5543.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5544_5603.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5604_5651.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5652_5711.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5712_5759.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5760_5831.png Burn_Rubber_Does_Not_Mean_Warp_Speed_5832_6023.png Burn_Rubber_Does_Not_Mean_Warp_Speed_6024_6179.png Burn_Rubber_Does_Not_Mean_Warp_Speed_6180_6311.png Burn_Rubber_Does_Not_Mean_Warp_Speed_6312_13211.png Burn_Rubber_Does_Not_Mean_Warp_Speed_13212_13991.png Burn_Rubber_Does_Not_Mean_Warp_Speed_13992_15071.png Burn_Rubber_Does_Not_Mean_Warp_Speed_15072_16475.png Burn_Rubber_Does_Not_Mean_Warp_Speed_16476_18971.png Burn_Rubber_Does_Not_Mean_Warp_Speed_18972_19151.png Burn_Rubber_Does_Not_Mean_Warp_Speed_19152_23279.png Burn_Rubber_Does_Not_Mean_Warp_Speed_23280_24719.png Burn_Rubber_Does_Not_Mean_Warp_Speed_24720_25835.png Burn_Rubber_Does_Not_Mean_Warp_Speed_25836_30095.png Burn_Rubber_Does_Not_Mean_Warp_Speed_30096_30467.png Burn_Rubber_Does_Not_Mean_Warp_Speed_30468_32903.png Burn_Rubber_Does_Not_Mean_Warp_Speed_32904_33995.png Burn_Rubber_Does_Not_Mean_Warp_Speed_33996_34271.png Burn_Rubber_Does_Not_Mean_Warp_Speed_34272_37067.png Burn_Rubber_Does_Not_Mean_Warp_Speed_37068_40007.png Burn_Rubber_Does_Not_Mean_Warp_Speed_40008_42347.png Burn_Rubber_Does_Not_Mean_Warp_Speed_42348_45155.png Burn_Rubber_Does_Not_Mean_Warp_Speed_45156_45239.png Burn_Rubber_Does_Not_Mean_Warp_Speed_45240_46739.png Burn_Rubber_Does_Not_Mean_Warp_Speed_46740_51059.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51060_51107.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51108_51155.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51156_51203.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51204_51275.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51276_51359.png Burn_Rubber_Does_Not_Mean_Warp_Speed_51360_51376.png