Burn Rubber Does Not Mean Warp Speed
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 46 | |
| Anzahl der Teile | 94 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/30648 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
RailsConf 201546 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
BitMAPWellenpaketVererbungshierarchieProdukt <Mathematik>ATMEDV-BeratungProgrammierungMultiplikationsoperatorComputeranimation
01:45
Umsetzung <Informatik>Gemeinsamer SpeicherGenerator <Informatik>Physikalisches SystemMomentenproblemMultiplikationsoperatorReelle ZahlWellenpaketPrimidealGeradeProgrammierungFamilie <Mathematik>Formale GrammatikDemoszene <Programmierung>Arithmetisches MittelBitArithmetische FolgeHyperbelverfahrenEreignisdatenanalyseExtreme programmingClientNP-hartes ProblemCodierungPerspektiveBitrateCodePhasenumwandlungMereologieSoftwareComputerspielIndexberechnungWarpingGradientHardwareVarietät <Mathematik>MAPCASE <Informatik>RuhmasseURLFlächeninhaltFreewareDatenverwaltungGesetz <Physik>BeobachtungsstudieBenutzerfreundlichkeitt-TestRechenschieberFehlermeldungArbeit <Physik>PRINCE2BildschirmmaskeTypentheorieComputeranimation
09:47
Automatische HandlungsplanungEinflussgrößeMultiplikationsoperatorDifferenteEin-AusgabeBitrateProgrammierungTUNIS <Programm>FrequenzFormale GrammatikWellenpaketDienst <Informatik>PhasenumwandlungComputerspielt-TestStandardabweichungRuhmasseLeistungsbewertungKontextbezogenes SystemUnendlichkeitCodeZahlenbereichVerknüpfungsgliedInverser LimesRegulator <Mathematik>Element <Gruppentheorie>MathematikStrömungsrichtungDickeSoftwareMAPMittelwertWeb SiteAutorisierungHinterlegungsverfahren <Kryptologie>OrtsoperatorTablet PCKartesische KoordinatenLeistung <Physik>Arithmetische FolgeZeitreihenanalyseProzess <Informatik>SummierbarkeitNichtlineares GleichungssystemARM <Computerarchitektur>InstantiierungErwartungswertGeometrische FrustrationRFIDGruppenoperationProgrammierumgebungAuswahlaxiomWikiBootenKreisflächeComputeranimation
17:49
WellenpaketHinterlegungsverfahren <Kryptologie>Zentrische StreckungMultiplikationsoperatorProgrammierungSystemplattformFormale GrammatikEnergiedichteProjektive EbeneSoftwareentwicklerArithmetisches MittelProdukt <Mathematik>ComputersicherheitProzess <Informatik>Automatische HandlungsplanungIterationSchlüsselverwaltungEDV-BeratungMinimalgradEinflussgrößeBitrateDruckverlaufOrtsoperatorSoftwareschwachstelleMailing-ListeEntscheidungstheorieSchnittmengeAdressraumErwartungswertTabelleKreisbewegungDifferenteVorhersagbarkeitUmwandlungsenthalpieVollständiger VerbandKonstruktor <Informatik>CodierungCASE <Informatik>ClientNP-hartes ProblemCodeWeg <Topologie>InstantiierungTeilbarkeitARM <Computerarchitektur>BeobachtungsstudieDatenstrukturWinkelDatenverwaltungMultigraphRechter WinkelLeistungsbewertungFunktionalGebäude <Mathematik>Dynamisches SystemArithmetische FolgeSoftwareFigurierte Zahl
25:52
TermCodierungPerspektiveHinterlegungsverfahren <Kryptologie>NP-hartes ProblemKartesische KoordinatenCodeProzess <Informatik>SoftwaretestProgrammierungEDV-BeratungARM <Computerarchitektur>HochdruckMereologieDatenstrukturVollständiger VerbandDesign by ContractArbeit <Physik>Produkt <Mathematik>MathematikNichtlinearer OperatorKonfiguration <Informatik>BereichsschätzungUnternehmensarchitekturFokalpunktBitrateAbgeschlossene MengeLeistungsbewertungMultiplikationsoperatorWellenpakett-TestSubstitutionZeiger <Informatik>Formation <Mathematik>TUNIS <Programm>DifferenteLesen <Datenverarbeitung>Element <Gruppentheorie>Arithmetisches MittelMetropolitan area networkSchätzfunktionPhysikalisches SystemTaskDynamisches SystemGeradeBildverstehenPunktEinflussgrößeSichtenkonzeptTuring-TestInklusion <Mathematik>Figurierte ZahlVerknüpfungsglied
33:54
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:13
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.
00:25
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. A lot better.
00:42
So a little bit about my professional background. I am a recovering marketer. I was in marketing and branding for ten years. I've been clean for almost two years. I'm very proud of that. In deciding to make that career switch, I attended a six-month super-intensive developer training program,
01:07
and I have been formally employed as a real-life 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.
01:23
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.
01:45
I also run the Denver chapter for Girl Develop It, 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.
02:02
I've been in exactly two apprenticeships since I graduated from the training program, and so as a noob, 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,
02:22
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.
02:46
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.
03:04
And so I just wanted to take one minute of our time and share that relevant scene with you.
04:14
I certainly don't want to come across as overly dramatic. I mean, developer apprenticeships are not as scary as blood-sucking vampires.
04:22
I 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.
04:45
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.
05:02
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,
05:21
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,
05:41
or in the extreme cases, survival. And yet, while I was learning to code in my developer training program, 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?
06:02
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 ten months post-grad developer training program for me to chill out on some of that anxiety.
06:21
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,
06:40
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,
07:01
or even speak up about what I was thinking and what I was feeling. And so it was this journey, kind of this 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,
07:20
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
07:41
a new generation of practitioners of a trade or profession. With an 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,
08:04
as most of the training is done while working for an employer who invests in the apprentice in exchange for continued labor, for an agreed-upon amount of time after the apprentice has achieved competencies that were defined in the program.
08:23
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 craftsman would employ the apprentice in exchange for food, lodging, and formal training in the craft.
08:44
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.
09:02
Okay, so they weren't worried about where my next meal was 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 apprentices, one would advance to journeyman years.
09:20
A journeyman is an individual who has completed an apprenticeship, and they are fully educated in a trader 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,
09:40
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.
10:04
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.
10:23
Then the journeyman would have to produce a sum of money and a masterpiece before they could actually gain that membership master within the guild. And if the masterpiece was not accepted by the masters, they could possibly remain a journeyman for the rest of their life.
10:42
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
11:05
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 were probably all pretty familiar.
11:20
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.
11:40
How about traditional engineers? Anyone? Bueller? No, three to five years. Marty is so excited over there. Three to five years. Okay, last one. Tattoo artist. Don't fail me now. Oh, that's a good guess. It's not. It's one to five years.
12:07
Okay, so key takeaways for me as I was reading about apprenticeships is that they take years. Like, a lot of years. And they are methodical. There are stages, there are levels, hours requirements, and then an application for master status and licensing.
12:26
And also that there is a commitment on both sides of the equation to that time and process, including committed and owed time after the formal apprenticeship period. So, if we circle back to developer apprenticeships and what's so scary about them,
12:45
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.
13:02
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, 3 months, 6 months. And also frightening is that unlike doctors, engineers, electricians, there is no licensing body,
13:24
no regulations or standards for the quality of curriculum or the quality of student that these programs are producing. And now let's consider formal developer apprenticeships post-grad. 3 months, 6 months, if you're lucky, you'll find one that's a year.
13:41
I mean, the vast majority are running at 3 to 6 months, very few at a year or 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.
14:00
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.
14:21
Just something that you 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.
14:41
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 Brin, scientist and science fiction author, said, The worst mistake of first contact, made throughout history by individuals on both sides of every new encounter,
15:06
has been the unfortunate habit of making assumptions. It often proved fatal. 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
15:21
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.
15:40
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,
16:02
you are immediately employable and handsomely compensated, and most importantly, you are nothing like an apprentice. Another assumption, advancing through levels of developer status. If you happen to start there, or from junior level to senior level, for instance,
16:20
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?
16:45
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 are ultimately set up to fail. Or employer frustration because progress is not meeting expectations
17:01
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,
17:20
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 succeed on the plan,
17:42
precisely as it was written, we are 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.
18:05
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?
18:21
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. I bring marketing, client management, and even some legal expertise,
18:44
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
19:01
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,
19:21
like weekly check-ins and scheduled mentorship and individual projects and 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,
19:40
so let's just let them do that because everyone is so busy in any way, really what's the point? An 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.
20:01
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?
20:24
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
20:43
around things like interpersonal skills, your cross-functional team dynamics, and mentoring them around gaining a deep understanding of the business of building software. We're also missing the time to just be an apprentice.
21:01
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,
21:21
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
21:40
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 is investing in mentors as teachers.
22:03
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.
22:22
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.
22:44
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
23:00
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
23:22
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.
23:42
I 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,
24:00
now you can adjust the tutelage and the expectations and you 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.
24:26
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.
24:44
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,
25:01
and 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,
25:25
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,
25:44
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,
26:02
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,
26:22
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.
26:42
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.
27:05
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.
27:23
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.
27:41
And consider apprenticeships of the Middle Ages lasting 7 years or plus 3 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.
28:05
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
28:23
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?
28:43
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
29:02
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,
29:24
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 systems view
29:41
and 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 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,
30:01
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 it what you want to get out, and that doesn't just mean the apprentice. Holistic value, measure more than just the hard coding skills.
30:25
And lastly, favor the marathon. We know becoming 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,
30:44
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 if some of them strike you as too radical, well then I hope that they at least plant a seed of ideation
31:04
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.
31:21
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
31:41
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. Make sure 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
32:02
to be good at that job. And conversely, 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.
32:20
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
32:40
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
33:01
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.
33:22
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 figure out where maybe they would fit in best. And if you're a small consultancy,
33:40
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.