Great Expectations: Power-Charging Apprenticeship Programs
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
Barrett, Louisa
Apprenticeships are a great way to ramp up a newbie, but these programs are much tougher to successfully implement than many organizations expect. It is a surprisingly large investment to guide someone through the ups and downs of their first gig as a developer, and if you aren't prepared it can be a bad experience for everyone involved. Let's dig into what makes a robust and empowering apprenticeship, from full team buy-in to setting clear learning goals to providing a clear path to the optimum final outcome: a new full time junior developer and a team dedicated to investing in education.
 Okay, so it is 2.40, so I'm going to go ahead and get started. I'm going to be talking about power charging apprenticeship programs today. And you are probably wondering, who is this lady? Hi. I'm Louisa. I work at the Turing School of Software and Design. I am the founding instructor and I'm currently the director of the front-end engineering program. And that means that I work with this guy. So I don't know if you're familiar with Turing, but this is Jeff Kasme. Here's our founder. He's not here today, so I can pick on him a little bit. So back to me now. So since I'm on the front-end team, I like design and I like code and I also like teaching. And that means that I basically spend my days hurting humans, talking about typography, JavaScript, and if you will excuse my pardon in my French, CSS. And I am extremely bad at Twitter, but this is my Twitter handle. And it's like it's really embarrassing how bad I am at Twitter, so just don't judge me. So I'm a front-end person. I am at a Ruby conference, so that's weird. Why am I here? Firstly I am extremely good at Ruby, as you can tell by this. And mostly jokes. Good at it. Okay. All right. Anyway, so what I'm actually here to talk to you about is apprenticeships. And so for the last couple of years, I'm also used to walking around when I talk, so if I keep walking away from the mic, please forgive me and I'll come back to it. So for the last couple of years, my whole job has been to figure out the best and most repeatable techniques to get people ramped up into junior dev level skill levels to do that really quickly and to do that really consistently. And obviously I'm working in a school, so I'm in a more education-based place. But that's essentially what an apprenticeship is. It's in a little bit more business-minded format rather than an education-based format. So I do this a lot. This is my job. And I just want to talk to you about it. And part of why I want to do that is because my background is in design. I was a designer for a very long time. I've been in the creative industries for many years before I switched over to writing code. And it was really interesting to me coming from the creative industry where apprenticeships and internships are just kind of like part of the game. And it's like expected that you will have had some sort of an apprenticeship or some sort of an internship at some point before you have your first real job. And often, again, because it's a creative industry, those jobs are those internships or those apprenticeships are often unpaid because of reasons like experience and you're passionate about it, which is a load of crap. But it was really interesting coming into software development because it was a very different kind of like mindset around them. They were a little bit less common. I think people took them a lot more seriously and I feel like part of the reason that they did that is because there's this expectation that you should be compensated fairly for your work in this industry, which is quite a fantastic thing, right? That's great. But it means that people take it a little bit more seriously and that people are more concerned about making sure that it's actually fair and that people are being treated right. But at the same time, that means that I feel like there are potentially fewer opportunities to get your foot in the door in an apprenticeship type situation at a company unless it's a really big organization that has a lot of wiggle room and funding for it. But the thing is that apprenticeships are really valuable to teams. I think that they are really great experiences for both the person who is the actual apprentice and then also the team that they're working with. And really the biggest thing is just to structure them correctly and just be mindful of how you're putting them together in order for them to really be successful and really be a good experience for everyone. So, yes, setting up a successful apprenticeship is not impossible and it is not scary. And they really are worth it. And part of that is just because it is so energizing to have somebody who's new to the industry as a part of your team. They are incredibly motivated. They're really excited and they're also just really fun to work with. They see things from like new perspectives and different angles and it's just really exciting and fun to be a part of it when you're on a team with someone like that. So, yes, all of you could absolutely build in a successful apprenticeship program and your team will be significantly stronger for it. So if you are still thinking that an apprenticeship program seems like it's just like kind of like a high risk time and money vacuum and you're kind of wondering if that investment is really going to pay off, yes, it will. In my experience, the benefits to the team and just like the general company ecosystem are actually really big. An apprenticeship can be, or just bringing on an apprentice is a really great way to re-energize a team even if you just have like, if you are able to have a team of just senior people, bringing on somebody who's brand new is a really energizing and fun thing to do and they can bring a lot of just joy and fun to the group that you may not expect. And remember, it also isn't something that's forever for either party, right? Like an apprenticeship is a termed thing that somebody's going to grow out of. They're going to grow into a more experienced role. They're going to be a junior. They're going to become a mid-level person at some point. They're going to move into a senior position at some point down the road. So like, they're super motivated. They know that there's a light at the end of the tunnel. They know that they're going to be progressing quickly. So they're going to be working really hard and they're going to get better really fast. And so investing in them at that point in their careers is really beneficial to you and them and it really will pay off quickly. So again, in conclusion, you absolutely can have an apprenticeship program and they will make your team better and you will have a lot of really new weird jokes, which is always great, right? More jokes. So the plan, you should have one. Perfect. Great. So again, like before you get started, the very first thing you should do is just make sure that your whole team, so like top down, understands like what the point of an apprentice is. And it is an educational learning relationship, right? So like you're bringing on someone who is there to learn from you and someone who you've committed to teaching for us that amount of time. And keeping that in mind that this is something that you have agreed to do, that you're like agreeing to teach someone and they're agreeing to learn from you. We're going to talk about some strategies that will help teams plan and prepare for a successful apprenticeship program. And there are three phases of planning that I'm going to be talking about today. So first, like what to do before you start an apprenticeship. So like systems and processes to have in place, things to do before you actually get rolling with it. How to hire for an apprenticeship. So how to actually find the right candidate and then hire the right person. And then just what to do during the apprenticeship. Like how do you keep somebody on track? How do you make sure that they're making progress and how do you keep the wheels on the bus? I guess is how you could say that. So those are the things we're going to be talking about and we're going to just dive right into what to do before you start an apprenticeship. So like most things that are worth doing, this does take a little bit of work to put a program like this together and that's okay. It's kind of like, it's not really that different than like when you start a new, like if you bring out a new client project or you just start a new software project, it's just planning. So in these phases, this is just sort of like strategy and planning and making sure everybody is on board. And like a new client project or a new software project, it's in your best interest to put about 5 to 10% of your time in upfront to make sure that you're in a good place to have things that you can like goals and a game plan to execute on throughout the duration of your program. So the work you put in should start before you even start thinking about interviewing candidates and it's really going to pay you back tenfold once you actually bring someone onto your team. So with that in mind, let's dig into it. So something to consider before you get started again is just put the wise before the house, right? So this is really trying to understand the reasons and motivations that are driving you to start a program like this. There's not necessarily like a wrong motivation or a right motivation, but there are different motivators and it's very important to just make sure that you're paying attention to that. Because if you are sort of angling, if you're kicking it at an angle that isn't really truly targeting the motivations and the reasons that you're doing this, you could potentially not have as successful an experience as you would otherwise. So wise behind bringing on an apprentice can, there can be a big range of reasons, like lots of different reasons why you might do this. And they might range from like educational, like you might feel like you really want to just bring someone into the industry and help them get a toehold and just get a good solid start. Or they might be financial, like maybe you're at a really small company and you need more hands on deck. And like the reality is that you don't have the budget to bring on a mid-level or senior person. And an apprentice is sort of like, okay, I'm going to get this person started, but I also, it's going to help me because I can actually like afford to pay them. And again, those are both valid reasons. There's not necessarily that there isn't like a right way or a wrong way to do this. It's just be honest about it and be clear with yourself, your team and the person you're bringing on so that everybody's really on the same page about like what's going on and why they're coming onto the team. So and because those two sort of like two spectrums of motivations are very different, they're going to impact how you actually approach a program like this. So if you tell yourself that you are going to help like a newbie get a toehold in the industry, that's going to really sort of direct your choices and how you structure things very differently than if what you need is somebody who is going to be able to actually hit the ground running a little bit faster and really start contributing to code because you just need more hands on deck. So just make sure that you're clear on that and then your planning and your execution will be more aligned. And again, just being honest with yourself about that will lead to more successes. So making sure that you are planning carefully, hiring strategically and then having an actionable curriculum strategy, which sounds scarier than it actually is, are going to make sure that you have set yourself up for success with your team. So before again, like before you bring on, before you start hiring anybody or anything like that, this is all still part of the planning phase of things. You want to make sure that you have buy-in from the whole team. So this is basically top down buy-in. Like you want to pitch this and sell it to your whole team. So what that kind of means is that you end up making sure that like management needs to understand like the reasoning behind this, why it offers value, and then your team should also be on board them like understanding that this is something that they're excited about and invested in. So everybody needs to be on the same page about how time and energy is going to be allocated for something like this. And then because people have an easier time saying yes when they can clearly see like the path to success, here are some ways that you can be strategic and communicate your plan to the whole team to get go ahead from everybody. So you want to make your case and you want to be specific about it. So you want to understand, you want to have a defendable business reason and like team building reasons for why adding this position is going to be beneficial. And you want to be like very explicit and direct around what roles everyone is going to be responsible for when you get someone on the team. And again like the stronger you can make a case for this now, the more your team will understand like where you're heading and where your head's at and that's like the plan. And they will be able to support you better. And again this comes from management down. So you want to go top down, everyone should be bought in, everybody should be on the same page. Because then you ultimately, what you want to do is be, you want to have it be as supportive as you can for this new person that you're bringing on. And again like the whole point of this is to just make it easy for the team to say yes to this. So you need to be prepared to explain why this program is valuable to the team and then to be clear about who is responsible for what. So just make sure that you have like a strategy and a plan around like how things are happening and when they're going to happen and all that. And some things you can dig into are to build a strong case for this. Know who the primary point person is going to be. So you want to make sure that you have someone who's going to be like an owner of this apprenticeship and they're going to be the primary mentor. You want to be clear about how key team members will have bandwidth in their schedule. So if it's possible to sort of like address scheduling issues and make sure that people aren't going to feel totally overloaded. So just sort of like being able to adjust schedules in such a way or just address scheduling issues in such a way to make sure that people actually have the bandwidth to support this person. And then just being clear that teaching actually makes your team a lot stronger. So if you have a team of very senior people, there are a lot of opportunities for teaching a brand new beginner that will make them better. Having to explain something at a really granular like specific level to somebody who doesn't understand the bigger picture is really difficult. And it's actually surprising how many senior people struggle with that. So bringing somebody on who's super junior and doesn't have a lot of exposure to these things is actually really great even if you have a primarily senior level team. It also brings on a lot of different perspectives and skill sets, especially, I mean, even if you're hiring from like a traditional CS program, but if you're hiring from like an accelerated training program or a boot camp, you're going to get all of this like life history and career experience that is really interesting and kind of exciting. So it's going to reenergize your team and it's going to bring on a lot of interesting perspectives and approaches to the work, which is great. And then you should also just be very clear about how your apprentice's time will be spent and how they're going to be progressively ramping up so they are able to take on more and more billable work. Like there's an expectation that initially you're going to be, you know, not have as much billable time and then as you taper off towards the end of your apprenticeship that you should be pretty much mostly billable, right? So be clear about that and then just have a game plan for how they're going to get up to that skill level so they are more billable. So then we have backwards planning. So this is something around, this is probably something that's going to be happening around the same time as your team buy-in conversations and this is something that's going to help you do that, right? So backwards planning is essentially helping you make a case for why this is doable and achievable and it also helps you just set up a game plan for how you're going to structure things, right? So when I'm talking about backwards planning what I'm essentially talking about is just curriculum planning. So it's basically like, so first of all, curriculum is not a scary word, you can do this. It's basically just saying that you are going to start out figuring out where the person needs to end up and then working your way backwards. So at the end of the program they should have this set of skills and I know that and then how do I actually break that down from day one to make them successful to hit that point that I need them to be at. So around curriculum planning, things that you can do to organize this is, so you start again, like you start with a list of skills and competencies that you want them to have mastery of at the very end of the program, right? So you're going to go ahead and make sure that they, you have been very clear and explicit about that. So we're basically starting at like the most, like biggest picture view and then we're working our way into a more granular level. So again, we start out with like, end of the program, where do they need to be? Then we work our way out from that, we work our way in from there. So we say like 10,000 foot view, how do I get them there? So this is when you start thinking about like if I need them to know this whole big set of stuff, how do I actually break that down into bite-sizable pieces so I'm not just like throwing them in the deep end and expecting them to know how to swim them. I haven't put little like water wings on them at all. So that's this next step. Then finally we kind of go down into a week by week breakdown of goals. So this is when we really start getting granular, we really start breaking this like bigger end goal down into these little pieces. And again, this isn't all that different from like project planning, right? So it's essentially like you are taking this big problem and you're breaking it into little pieces that don't seem so intimidating. But again, this is just about education. So we're dealing with how do we take this larger problem and then we break it down into little pieces. So this is going to be something where like you figure out from week one, what do I need them to know? And then I'm going to build on that and you're just going to build your way upwards towards the end of the program. You also need to understand what success looks like at all of these various stages of the apprenticeship and then also additionally. So you need to understand what success looks like and then in parallel with that you need to understand what kind of a plan do you have if they start falling behind. And it's likely that they'll have several different things that they need to be working on at the same time or that they'll be ramping up on and not everybody learns the same skills at the same pace. So it could be that there are certain things that they're really excelling at and then certain things that they're sort of struggling with. So just being prepared for that and then having some sort of a game plan so you can kind of hop in and start helping them out if they get stuck. And then another thing is just to be sure that you have a clear, you have clear ways that someone can understand what skills they need to know and then how they can improve on those. And again to get a whole team buy in it's important that you have set up this information in a way that is accessible to the whole team so everybody's able to be on the same page and just be clearly communicating at the same time to both the apprenticeship and each other about where they are at. And this is also really helpful because the apprentice can then sort of like self assess along the way and it's not just totally on you to like have to hand hold them and tell them where they're at. So again it also just allows the team to be aligned and you're not getting mixed messages from everyone. All right. So again to understand how to track progress for once your apprentice gets started. This is something that is a little bit tricky because it can feel a little bit ambiguous and you've got a lot of different things that you need to kind of pay attention to because if you like software is not the simple things you need to have there's going to be multiple things that they're ramping up on at the same time. And so you need some sort of a rubric that you can like balance against and check against so people understand where they're at and they have like actionable steps that they can take to get better at certain specific skills. And so things that I've seen great success with are when we have like a tiered scoring system essentially. So these can be either rankings from like red to green so red would be something that someone is struggling with in green is something that they're just correct their crews and they don't need a lot of help with that. You could have like sort of a number system so one to four or even just something like from novice to expert. Right. So you can just have just some sort of ranking that somebody understands the tiers and like the structure that they can keep working their way up from. It should be kept some somewhat simple. You don't want to get so complex that it's overly tricky to understand or to use. So I'd say probably between three and five sort of skill levels per skill that they're mastering so different levels that they can work their way up from. And it should really have clear and explicit steps that explain how to move forward from one level to the next. Something else to consider is just semantics. Right. So the phrase things really matters especially when someone's in a situation where they're learning something new that they're a little bit uncomfortable with. And it can actually have a really big impact on people if you use poorly chosen words and you can really negatively impact someone's progress and their growth. So you don't have to treat them like a delicate flower. You don't have to be like a really warm and fuzzy about everything. But it is important to just use language that builds them up rather than tears them down. So as an example of that, here's an example of some positive language that we use at Turing. So this is a very high level breakdown of just the language that we use for students in the first few weeks of Turing. So you see we have a breakdown from novice, advanced beginner, proficient to exceptional. We have four levels of skills and then within there, so novice is defined as, and again, this is very high level. This isn't broken down into granular sections of skills. This is just a big picture, 10,000 foot view of how they're doing. So it says, can function but needs a lot of oversight for novice. Advanced beginner is can function with very little oversight. Proficient is can confidently implement code without the need for rigid feedback. And then exceptional is understands and execute advanced concepts. So there's a pretty clear progression of skills and understanding there. And it allows them to, they can go and read this and they don't need us to necessarily sit next to them and guide them. And that's really useful because it means that they're able to take control of their own learning and you don't have to can't hold them quite so much. Then we have another slightly more in-depth example. So this is an example for just get how they understand version control. And again, we have the four-tier breakdown from novice to exceptional. With novice essentially just saying they can use commits. They can articulate what a commit is. So that's good. Hooray! And then they also, but they're kind of taking big commits and then shove them all up to master, which is a little bit of a dangerous game. And then we take it up to exceptional, which is that they know how to reset to previous commits, rebase large sets of small commits, and then if applicable, use other advanced git maneuvers. So we have a pretty drastic change in their understanding of this specific skill set, which is really useful. And so again, you would just sort of break down each sort of step of the skills that you'd want them to understand in this way so they can go in and self-assess. And this should be something that is available and accessible to your whole team. So everyone who's working with the apprentice, everyone who needs to support them and guide them, so everyone's on the same page and being consistent with the messaging that they're giving them. So everyone's just communicating consistently to them. And they can also self-assess. So those are things that you should handle before you get a human on board. So that's going to be something that's going to allow you to be in a good place to just start working with them once you get somebody on board. You're going to have all your systems in place, your teams on board. You have a game plan. You know where you need them to be. And then you need to actually find the right human. So it's not really all that different than hiring for another dev position. The biggest thing is that you're looking for somebody, you're investing in someone as a prospect rather than someone with a proven track record. So it takes a little bit of, I guess, potentially a little bit more finesse than just hiring someone who you know. You've seen their work at other companies. You've seen them speaking at conferences. You've seen them around. You've seen their blog posts. You know what they've been doing and you know they're really good. This is someone who's kind of an unknown and it's a little bit of a risk. But there are definitely things you can look for that will be really helpful in guiding you to find the right person and the right fit. And that's actually a big part of what I do at Turing. So a big part of my job is to really just quickly and accurately gauge who has the right personality or just attitude and perspective to be successful in this type of environment where it's a little bit less supported and it's something that they can learn on their own and they can be successful there. So things that I look for. So I tried not to use GIFs but I should have put a GIF in here. Anyway, so something that, I'm sure that most companies have some sort of structure around how to evaluate people for the role that they're looking to fill and it's super useful to do that for apprentices as well. And you also have to just consider like what are your goals for this person? Like where do you want them to land and what do you actually need them to do? Like are you looking for somebody who's going to be just a hot shot right out of the gate that has leadership potential and who's going to make your company and probably your program just look amazing because they're just really good but potentially you're going to get poached away for something a little bit more fancy pretty quickly like you never know. Or do you want somebody who's going to be really solid who's going to just get into your code base and just learn it really, really deeply and really effectively and be happy to hang out for a couple years? Like you understand like where you want this person to go and what they're going to do for your program and then hire appropriately, right? So not all personalities are going to fill the same role in the same way. So things to look for are just like thinking about how they're going to fit in the group. So there's this interesting idea when you're thinking about group dynamics and you'll see this a lot in just companies and organizations and it's this like 1080-10 rule which means that essentially when you have a group of people they'll be broken out into three groups. So you'll have the top 10%. These are sort of like the leaders. These are the people who are, they're going to excel kind of no matter where you put them, they're really motivated, they're going to push really hard and they really just sort of are driven to lead. These are the people who tend, you kind of tend to gravitate to, you're like oh I want to hire that person but they're also the people who maybe that's not actually what you want, right? They're the people who are kind of going to be the movers and shakers and they might mix things up and change things a little bit. The middle 80%, these are the people who are more than happy to do the work that is asked of them, they're not going to rock the boat, they're going to be really consistent, they're solid, they're really stable and they're going to execute really well and they're consistent. This is like obviously 80%, this is the majority of people that you end up working with. And then there's the bottom 10% which are, they're kind of like the dumpster fires that are cleverly disguised as humans. So we're going to just assume that you can tell when those people are in front of you and you're not going to hire them so we're going to focus on the top 10% and that middle 80%. And again like the group that you want your apprentice to come from really just depends on what your long term goals are for that person and for that role. And so you just have to make sure that you're hiring from the right group. So things to consider when you are looking for your apprentice, that attitude really counts for a lot. So I've worked with around 150 people that have taken from like zero to getting jobs and I focus on the first section of their time at Turing. So I'm like mama bearing them when they're in their first like, what is happening to me phases of school? And so the patterns, I've gotten very good at like noticing patterns and behaviors that indicate someone is going to be successful in this environment and then which patterns indicate that somebody might not be. And people who really excel in these types of situations and these sort of like semi-self-directed learning environments have a shared set of qualities. So things that they tend to do, they're very engaged. So these are people who, they're very curious, they want to go investigate. If they see something they don't understand, they don't wait for you to kind of give them a nudge to go check it out, they're just in it. They start checking it out, they start digging around and investigating things on their own. And they also, generally because they're really curious and they're really engaged, they find ways to make it fun for themselves. And fun makes you learn things better. It makes you learn faster if you're able to make things interesting for yourself. It means that learning is going to come easier to you. They're also loyal. These are people who like if things get, if things get harder kind of go off course because this is a business and you never know like maybe you're going to lose a client, maybe something weird is going to happen, they're not going to, they're not going to bail, they're not going to freak out, they're going to like, they're going to stay the course. They're vocal and they're honest. So these are people who, they're not going to be confrontational and they're not going to be irrational, but if something is wrong or if they don't like something, they're going to speak up and they're going to talk to you about it. You have high standards, they have high standards. These people are often top performers. They're used to excelling at things, they understand what success looks like and they understand how much work it takes to get to that point. So they understand effort and they understand what it takes to get there. And then they're dedicated. So again, if you give them something, they're going to do it to the best of their ability and they're not, if they get stuck, they're going to ask you for help. Great. Obviously like again, when things get hard, they're not going to bail on you, they're going to keep cranking, they're not going to give up even if things get uncomfortable because they know that things will get better and that they'll grow. And then they're just good natured. Learning is hard, learning the program is hard. You want to be working with someone who's going to make it a fun experience for you and for them. So and then again, like you have that, it's like it's one thing to have like that list of like what to look for, but then it's another thing to actually be able to like identify that in a candidate. Like how do you actually know that they're really like that? It's very easy for some, I mean some people are really good at just jazz-handsing their way through interviews and then they show up, show up on day one and you're like, oh, you are not who I thought you were. So it's like how do you avoid that, right? So that's a little bit of a tricky thing. So it's important to start to think about like how do you separate the people who are really great from the people who are just really good at interviewing. So things to look at, their track record, what have they been up to? Like have they actually shown that they are able to tough out hard things? When things get hard, do they bail? Or do they tough it out? Have they been floating out like as Wayne from Wayne's World says? He has many name tags and hair nets. So like you don't want someone who's like that. You want somebody who's able to show them that they can like hang in there, tough it out, grow in a role and be there through the hard times and the good times. Again you want to show that they're able to like tough it out through difficult times. So this could be shown in a previous career, like whatever that is, I don't care if they were like an attorney or if they were working as a line cook. There are difficult things in every job and there's potential to demonstrate that they're gritty and tough and can handle things in any position they've had before. Or in school, right? So like if they were able to deal with a difficult program or just get through school in a way that is successful, there are many ways that they could show this to you. And essentially what you're just looking for is that they're able to make steady and consistent forward progress when they set their minds to doing something. And then another thing to think about is just how do they like really pay attention to how they're answering questions. Again like the jazz handsers, they're going to be trying to like target what they think you want to hear and they're going to tell you that. But really, if you pay attention to them and if they're thinking about how they take your question and they apply it to their own experiences, that's important. So be mindful if you think that they're just telling you what you want to hear or if they're actually taking your question and answering it truthfully. And to help you see if this is what they're doing, you can set up a situation where you're asking leading questions where you might say like, what would you do and set in an example situation? Like if a client calls you and they're really upset about something, what do you do? How do you handle it? They might answer, they might tell you what they might do hypothetically and then you say, like you listen to it, you hear them out and you say, cool, like great, that's awesome. Can you give me an example when you did that in a real situation? Tell me when you actually did that. And someone who actually has done that will tell you about it or that's how they would answer the question initially and someone who never has and is just sort of like playing to your question might not have that answer for you. It's also useful, so something that I've seen, especially with apprenticeships, is that oftentimes that, like the actual code challenge gets passed over because people just assume that this person is going to learn on the job, I don't really need to do a code challenge with them, that's not something that's super important. But it actually is, right? And it's less about should I hire this person or not because you understand that they don't know everything and they may be pretty soft in certain areas, but it's more around just so on day one when they come in, you know where they're coming from and you know where their skills are. So this is just to kind of help you understand what your starting point is. So yeah, it just gives you an idea of like, do they understand the language, what's their handle on syntax, do they understand what normal workflow looks like, do they understand version controller, like how to pair with people, just basic stuff around just experience with the industry. And then again, keep your end goals in mind. So have a plan, like just keep your eye on the prize of like, where do you want this person to end up at the end of your program? Do you want them to be a part of your team for a long time or do you want them to come through the program, be really successful and then like spread their wings and go somewhere else? Like who knows? Be mindful of that and then hire appropriately and gauge appropriately. All right, so you have done all your planning before you started an apprenticeship, you have hired the right person, you have a plan, your whole team is on board, so now what do you do? Great. How do you get it all together? So when you are hiring someone who's never worked in the industry before, onboarding is a little bit different than someone who understands your routine and knows what to do with everything. So it's a great idea to just get some things in place to have one central location where all of this information is available again to the apprentice and the rest of your team so everyone's on the same page about things. A very sort of simple low effort way to do this is to just have like, you can make a document, you can just like open, you can do something in Google Docs, have some sort of a calendar or something, or you have all the relevant and important links in one place so your apprentice can just bookmark one thing and then they have access to everything so they don't have to chase it all around. And things that they should, they might need could include what repos they need access to and then who's going to be taking care of that for them, who's going to actually give them access to all these things. Any specific systems set up that they need to have before you get started? So they have access to all, again, so they have access to this. They know where to go, they know where to look for it. Any communication channels that they should have access to before you get started? You want to, that means like, if it's Slack, HipChat, whatever, make sure that they're in the main channels that your team communicates with so they're able to hit the ground running and they're not sort of out in the cold and feeling a little bit ignored. Any important calendars? Calendars are great. That's always important again so you can track timelines. This is also a place where you can put all of those details around like goals for where they need to be every week. That's also great. And then just directions for how to contribute to a code base. How does your team follow specific rules? You can't assume that this person has done this before so it's important to make sure that it might seem a little bit silly or a little bit obvious, but this is someone who hasn't worked in this industry before so silly and obvious is okay. It's not silly. It's good. So just any sort of directives around how to contribute to code bases and giving them enough information that they can kind of dive right in and start taking a crack at contributing. And then also just if there are meetings like stand-ups, team meetings, staff meetings, whatever, make sure that they understand when that is so they're able to go to that when they need to. It's also important to have a syllabus and a schedule. So again, calendars and then some sort of a structure for your curriculum. Again, this is all about communication and your calendar is going to map out expectations and timelines that are going to allow your apprentice to have a clear upwards trajectory of skills and progression that you expect them to be hitting. And this is something that is going to just allow them to so they can keep track every week as they're working. So for your syllabus, again, it's your learning goals for every week. And it gives the apprentice a place to see where they're headed and what they need to be focusing on. That could include like a list of useful resources. So if there are tutorials, documentation, things like that that would help them get hit those goals for that week, that's a great place to put it. Assignments. So we'll talk about what that might look like in a minute, but you could potentially have like assignments that they could be working on. So outside of just like teamwork or like billable work, they could have things that they're actually working on to like just keep improving and then checks for understanding. So ways that they can actually confirm that they're learning what they need to be learning. And this just takes some of the mystery out of the learning process because again, it's very explicit and it's very clear and it's giving them a clear path forward with a clear like upward trajectory of steps and that they should be taking. Okay, so again, during when we are evaluating progress, this kind of comes back to that idea of that rubric that we talked about a little bit from like novice to exceptional or one to four, those kinds of ideas. It's important to understand that you have a way to track that they actually are making the progress that you need to be making. So if we consider our evaluation rubric again, this gives us clear actionable documentation of like what understanding and progress looks like and it allows them to keep up a steady upward trajectory of progress as they keep working through the program. And then again, like for the actual sort of like assignments or things that they can be working on as they're growing and learning, this idea of a breakable toy is really useful. So this is essentially like a little project that's owned by the apprentice. It's a code base that's just fully owned by the apprentice and it has a lifespan that's the length of the apprenticeship. And this is an interesting idea because it allows you to, it's non-billable code, it's owned by the apprentice and it allows them to have a thing they can break without worry that they're going to like break an actual production code base. And it's also something that you can strategically just match learning goals with like features that you're having to build on this breakable toy. It gives them space to kind of get goofy and weird and have fun with it. So it allows them to have the freedom to sort of play with their code. It allows them to like kind of pick a topic or something around about the project that they're really excited about and want to like play with. And that can be something that like trickles upwards into the rest of the team. Having fun and just building things because it's a fun project is really great. Another thing about this is it is really fun. You can just get weird with it and have fun. So one of the ways that, again, learning happens the most when you're in a place of just goofing around and having fun with things. So this is a great place to like fight through the hard problems because it's a project that's like a little bit of, it's just, it's near to their heart and they just really care about it. So something silly where they don't have the pressure of the actual client work is important. Something to keep in mind. An apprenticeship should be a safe place to fail. Learning is part of learning. Like when you're learning to ride a bike and you first take the training wheels off and you realize that you have to think really hard about riding the bike and staying on the bike and then you're going to fall off the bike a lot with that point. The more you're thinking about it, the more you're going to fall off of it and that's okay. And then gradually you realize that you have to think about the bike less and then eventually you realize that you're not thinking about the bike at all and you're just getting on the bike and riding away. And that's okay. If they fall off the bike, if they break things, that's okay. It's the same deal with software is riding a bicycle. You have to just encourage them to keep getting back on the bike and you have to let them break things. Don't make a huge deal out of it, but let them know that they did it and then make them fix it. Don't fix it for them. Don't follow them around. They're not delicate flowers. They can fix it themselves. Be supportive and then help them when they need it. And again, as you move forward, they should be able to do that with less and less and less hand holding. And then what do you do if the worst happens? Let's say you get started. The team was really into it. You found someone you thought was going to be a really great fit and then things start going sideways. Maybe you realized that this person you thought was going to be a great fit, maybe isn't meshing them with your team, maybe they're not learning at the rate that you needed them to. There could be many things that are happening that aren't, I mean, that this isn't going to work out. Just be honest and upfront about it. Things that I've seen happen sometimes is that apprenticeship programs can get dragged out well beyond their useful lifespan. And that doesn't do the team any favors. It doesn't do the apprentice any favors. They probably know that they're struggling at that point and keeping them around in that way isn't really doing them any favors. It's not kind. So it's better to just call a spade a spade if it's not working out. It doesn't mean that they can't do this. It probably just means that this isn't the right fit for them. Or maybe they're okay, but you ran out of money. Like, that could happen too. Maybe you lost a big account. Maybe you lost a client. Maybe just the business, just something happened to the business and you lost users or something. That's okay. That happens. But never put someone, especially an apprentice, don't put someone in a position where you can't pay them and you want them to work for experience. So if you get to a point where there is not money for them, again, cut them loose. Let them know what's happening. Keep them in the loop and then cut them loose. And the thing is that bad things happen. It's okay. Just be fair and be honest about it and really do your best to set them up for success. And try to help them land on their feet. So the way that an apprenticeship ends, whether it's the happy path where you now have a new junior dev on your team who's just crushing it and kicking ass and doing everything perfectly, or you have someone who just didn't work out for whatever reason, the way that that ends says a lot about your team. And if worst case scenario happens and it's not working out, the way that you handle that and if you're able to end on good terms with this person and support them and really still try to help them land on their feet speaks very highly about you and your team. So again, just make sure that you are being respectful and kind for everything. And then I just have thanks to people who have helped me. And then, yeah, some resources. That's it. Thank you. For self mentorship. Okay, so the question is how would you adapt this advice for self mentorship? There are actually several, there are some great apprenticeships that have sort of like open source curriculum that they set up. There are also some schools that have like their curriculum that's online. Sparkbox has a really great, they have a really, like if you go on GitHub and just like Google Sparkbox, you can find them. They have a very like clear, direct, just like curriculum path for their apprenticeships that has lots of like tutorials, lots of like documentation, lots of things like that around there and then there's also various schools and things. So a lot of it's the same thing. Like you figure out, it's like that backwards planning is super valuable. So if you think about where you want to land and just start like working, like figuring out like from where you want to be and then taking small steps forward, does that answer your question? Yeah. Okay, so the question is what is sort of like thoughts on taking an apprentice cohort rather than having them working together rather than having individual apprentices sort of like dividing, conquer, solo on side projects and things. I think that there's a lot of value in having like your battle buddies, right? So it's the same thing like in school. Like you have a group of people, you have a cohort that they're there to support you. They're there to bounce questions off of their people who are at the same, a similar level to you. So maybe you don't feel quite as self-conscious if you get stuck on something that you think might be a little bit silly. I think that there's a lot of value in that. I think there's also value in kind of just if you're like, if you're in a program that only has one apprentice kind of being like the only person there, like the lone wolf, there's also value in that and having to just sort of get in there and just force yourself to talk to the senior people who might be intimidating. But I think they're absolutely, if you are in a position where you can have a cohort of people who can like support each other, I think there's a lot of value in that. Sure. Sure. Okay. So the question is like how do you sort of keep your bias, your sort of like internal biases from impacting the way you're hiring decisions, even if like some of the things that you're sort of hiring for tend to maybe be a little bit more generally considered like masculine. So I think something to consider with that is, and part of that is just like the interview process and setting this person up to feel like comfortable in that. And you'll find that it's interesting because like we see this also in our interviewing students as well. You'll have people who come from these not like non white guy backgrounds and they'll come into the interview and they'll sort of start out with the normal like maybe I'm a little bit more quiet, a little more reserved and then you start talking to them and you ask them the right questions and you realize that like they're crushing it and they're amazing and that they're super smart and they're really good and they have opinions and they're able to do these things. And I think a lot of it is just setting up the interview process in a way that allows people to have room and space to tell their stories really effectively and to be safe. So some of that is just forcing yourself to make sure that your interview process is structured in a way that you're not intimidating people, you're not making people uncomfortable. It's also about outreach as well, right? So making sure that you are like getting word of your apprenticeship out there so people who are maybe from these different more diverse backgrounds know about it and they're able to talk to speak to it or to see it and apply for it. Does that answer your question? Yeah, so I think absolutely the expectation should be set that in the beginning of the oh sorry, so the question was just like the balance of like billable work versus non billable work during the course of the apprenticeship. Is that correct? Okay. So, yeah, so if we're talking about, so billable work, so first just what I mean when I say billable work, like when you're on the job, when you're going to like your time sheet and you're putting in what I did today, billable work would be the things that are actually the tasks that you've done that are allowing the company to make money. So that could be like actually pushing production code, like doing things like that, things like meetings or like internal meetings or like reading documentation or doing tutorials or something like that, that's non billable. But like actually like writing production code and like pushing that up and getting that live, that's all part of like your billable hours. And as an apprentice, part of this role and part of this job is that you are learning. So what it should be that in the beginning, your hours are skewed more heavily on the non billable side. So you're working on like your breakable toy project. You're working on something that isn't necessarily contributing to the inflow of cash to the company, but you are still growing and you're still learning really well. And so, but the idea is that in the beginning, you're going to be learning, you're going to be ramping up and figuring all this stuff out. And then during the course of the apprenticeship, you should be that ratio billable to non billable should flip and you're going to be having almost basically by the end of it, you should be at sort of like normal billable hours for a junior dev. So whatever that breaks down to for that company, so I'm not sure like what percentage that would might be per company, but like there are certain sort of like acceptable amounts of hours that should be billable. So you would want to by the end of it, the idea would be that you'd be at that point and then you'd have less time dedicated to like learning and that sort of thing. And then in the beginning, it'd be much more heavily skewed towards learning. Did I answer your question? Cool. Any other questions? All right. Thank you so much. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thanks everyone. Take care. Thanks MissIFJ. Oh, man. Thanks. Thank you. Thanks so much. Thank you. Thank you. Thanks. Thank you. Thanks.
 Okay, so it is 2.40, so I'm going to go ahead and get started.  I'm going to be talking about power charging apprenticeship programs today.  And you are probably wondering, who is this lady?  Hi.  I'm Louisa.  I work at the Turing School of Software and Design.  I am the founding instructor and I'm currently the director of the front-end engineering  program.  And that means that I work with this guy.  So I don't know if you're familiar with Turing, but this is Jeff Kasme.  Here's our founder.  He's not here today, so I can pick on him a little bit.  So back to me now.  So since I'm on the front-end team, I like design and I like code and I also like teaching.  And that means that I basically spend my days hurting humans, talking about typography,  JavaScript, and if you will excuse my pardon in my French, CSS.  And I am extremely bad at Twitter, but this is my Twitter handle.  And it's like it's really embarrassing how bad I am at Twitter, so just don't judge  me.  So I'm a front-end person.  I am at a Ruby conference, so that's weird.  Why am I here?  Firstly I am extremely good at Ruby, as you can tell by this.  And mostly jokes.  Good at it.  Okay.  All right.  Anyway, so what I'm actually here to talk to you about is apprenticeships.  And so for the last couple of years, I'm also used to walking around when I talk, so if  I keep walking away from the mic, please forgive me and I'll come back to it.  So for the last couple of years, my whole job has been to figure out the best and most  repeatable techniques to get people ramped up into junior dev level skill levels to do  that really quickly and to do that really consistently.  And obviously I'm working in a school, so I'm in a more education-based place.  But that's essentially what an apprenticeship is.  It's in a little bit more business-minded format rather than an education-based format.  So I do this a lot.  This is my job.  And I just want to talk to you about it.  And part of why I want to do that is because my background is in design.  I was a designer for a very long time.  I've been in the creative industries for many years before I switched over to writing  code.  And it was really interesting to me coming from the creative industry where apprenticeships  and internships are just kind of like part of the game.  And it's like expected that you will have had some sort of an apprenticeship or some  sort of an internship at some point before you have your first real job.  And often, again, because it's a creative industry, those jobs are those internships  or those apprenticeships are often unpaid because of reasons like experience and you're  passionate about it, which is a load of crap.  But it was really interesting coming into software development because it was a very  different kind of like mindset around them.  They were a little bit less common.  I think people took them a lot more seriously and I feel like part of the reason that they  did that is because there's this expectation that you should be compensated fairly for  your work in this industry, which is quite a fantastic thing, right?  That's great.  But it means that people take it a little bit more seriously and that people are more  concerned about making sure that it's actually fair and that people are being treated right.  But at the same time, that means that I feel like there are potentially fewer opportunities  to get your foot in the door in an apprenticeship type situation at a company unless it's a  really big organization that has a lot of wiggle room and funding for it.  But the thing is that apprenticeships are really valuable to teams.  I think that they are really great experiences for both the person who is the actual apprentice  and then also the team that they're working with.  And really the biggest thing is just to structure them correctly and just be mindful of how  you're putting them together in order for them to really be successful and really be  a good experience for everyone.  So, yes, setting up a successful apprenticeship is not impossible and it is not scary.  And they really are worth it.  And part of that is just because it is so energizing to have somebody who's new to the  industry as a part of your team.  They are incredibly motivated.  They're really excited and they're also just really fun to work with.  They see things from like new perspectives and different angles and it's just really  exciting and fun to be a part of it when you're on a team with someone like that.  So, yes, all of you could absolutely build in a successful apprenticeship program and  your team will be significantly stronger for it.  So if you are still thinking that an apprenticeship program seems like it's just like kind of  like a high risk time and money vacuum and you're kind of wondering if that investment  is really going to pay off, yes, it will.  In my experience, the benefits to the team and just like the general company ecosystem  are actually really big.  An apprenticeship can be, or just bringing on an apprentice is a really great way to  re-energize a team even if you just have like, if you are able to have a team of just  senior people, bringing on somebody who's brand new is a really energizing and fun  thing to do and they can bring a lot of just joy and fun to the group that you may not  expect.  And remember, it also isn't something that's forever for either party, right?  Like an apprenticeship is a termed thing that somebody's going to grow out of.  They're going to grow into a more experienced role.  They're going to be a junior.  They're going to become a mid-level person at some point.  They're going to move into a senior position at some point down the road.  So like, they're super motivated.  They know that there's a light at the end of the tunnel.  They know that they're going to be progressing quickly.  So they're going to be working really hard and they're going to get better really fast.  And so investing in them at that point in their careers is really beneficial to you  and them and it really will pay off quickly.  So again, in conclusion, you absolutely can have an apprenticeship program and they will  make your team better and you will have a lot of really new weird jokes, which is always  great, right?  More jokes.  So the plan, you should have one.  Perfect.  Great.  So again, like before you get started, the very first thing you should do is just make  sure that your whole team, so like top down, understands like what the point of an apprentice  is.  And it is an educational learning relationship, right?  So like you're bringing on someone who is there to learn from you and someone who you've  committed to teaching for us that amount of time.  And keeping that in mind that this is something that you have agreed to do, that you're like  agreeing to teach someone and they're agreeing to learn from you.  We're going to talk about some strategies that will help teams plan and prepare for a successful  apprenticeship program.  And there are three phases of planning that I'm going to be talking about today.  So first, like what to do before you start an apprenticeship.  So like systems and processes to have in place, things to do before you actually get rolling  with it.  How to hire for an apprenticeship.  So how to actually find the right candidate and then hire the right person.  And then just what to do during the apprenticeship.  Like how do you keep somebody on track?  How do you make sure that they're making progress and how do you keep the wheels on the bus?  I guess is how you could say that.  So those are the things we're going to be talking about and we're going to just dive  right into what to do before you start an apprenticeship.  So like most things that are worth doing, this does take a little bit of work to put  a program like this together and that's okay.  It's kind of like, it's not really that different than like when you start a new, like if you  bring out a new client project or you just start a new software project, it's just planning.  So in these phases, this is just sort of like strategy and planning and making sure everybody  is on board.  And like a new client project or a new software project, it's in your best interest to put  about 5 to 10% of your time in upfront to make sure that you're in a good place to have  things that you can like goals and a game plan to execute on throughout the duration  of your program.  So the work you put in should start before you even start thinking about interviewing  candidates and it's really going to pay you back tenfold once you actually bring someone  onto your team.  So with that in mind, let's dig into it.  So something to consider before you get started again is just put the wise before the house,  right?  So this is really trying to understand the reasons and motivations that are driving you  to start a program like this.  There's not necessarily like a wrong motivation or a right motivation, but there are different  motivators and it's very important to just make sure that you're paying attention to  that.  Because if you are sort of angling, if you're kicking it at an angle that isn't really truly  targeting the motivations and the reasons that you're doing this, you could potentially  not have as successful an experience as you would otherwise.  So wise behind bringing on an apprentice can, there can be a big range of reasons, like  lots of different reasons why you might do this.  And they might range from like educational, like you might feel like you really want to  just bring someone into the industry and help them get a toehold and just get a good solid  start.  Or they might be financial, like maybe you're at a really small company and you need more  hands on deck.  And like the reality is that you don't have the budget to bring on a mid-level or senior  person.  And an apprentice is sort of like, okay, I'm going to get this person started, but I also,  it's going to help me because I can actually like afford to pay them.  And again, those are both valid reasons.  There's not necessarily that there isn't like a right way or a wrong way to do this.  It's just be honest about it and be clear with yourself, your team and the person you're  bringing on so that everybody's really on the same page about like what's going on and  why they're coming onto the team.  So and because those two sort of like two spectrums of motivations are very different,  they're going to impact how you actually approach a program like this.  So if you tell yourself that you are going to help like a newbie get a toehold in the  industry, that's going to really sort of direct your choices and how you structure things  very differently than if what you need is somebody who is going to be able to actually  hit the ground running a little bit faster and really start contributing to code because  you just need more hands on deck.  So just make sure that you're clear on that and then your planning and your execution  will be more aligned.  And again, just being honest with yourself about that will lead to more successes.  So making sure that you are planning carefully, hiring strategically and then having an actionable  curriculum strategy, which sounds scarier than it actually is, are going to make sure  that you have set yourself up for success with your team.  So before again, like before you bring on, before you start hiring anybody or anything  like that, this is all still part of the planning phase of things.  You want to make sure that you have buy-in from the whole team.  So this is basically top down buy-in.  Like you want to pitch this and sell it to your whole team.  So what that kind of means is that you end up making sure that like management needs  to understand like the reasoning behind this, why it offers value, and then your team should  also be on board them like understanding that this is something that they're excited about  and invested in.  So everybody needs to be on the same page about how time and energy is going to be allocated  for something like this.  And then because people have an easier time saying yes when they can clearly see like  the path to success, here are some ways that you can be strategic and communicate your plan  to the whole team to get go ahead from everybody.  So you want to make your case and you want to be specific about it.  So you want to understand, you want to have a defendable business reason and like team  building reasons for why adding this position is going to be beneficial.  And you want to be like very explicit and direct around what roles everyone is going  to be responsible for when you get someone on the team.  And again like the stronger you can make a case for this now, the more your team will  understand like where you're heading and where your head's at and that's like the plan.  And they will be able to support you better.  And again this comes from management down.  So you want to go top down, everyone should be bought in, everybody should be on the same  page.  Because then you ultimately, what you want to do is be, you want to have it be as supportive  as you can for this new person that you're bringing on.  And again like the whole point of this is to just make it easy for the team to say yes  to this.  So you need to be prepared to explain why this program is valuable to the team and then  to be clear about who is responsible for what.  So just make sure that you have like a strategy and a plan around like how things are happening  and when they're going to happen and all that.  And some things you can dig into are to build a strong case for this.  Know who the primary point person is going to be.  So you want to make sure that you have someone who's going to be like an owner of this apprenticeship  and they're going to be the primary mentor.  You want to be clear about how key team members will have bandwidth in their schedule.  So if it's possible to sort of like address scheduling issues and make sure that people  aren't going to feel totally overloaded.  So just sort of like being able to adjust schedules in such a way or just address scheduling  issues in such a way to make sure that people actually have the bandwidth to support this  person.  And then just being clear that teaching actually makes your team a lot stronger.  So if you have a team of very senior people, there are a lot of opportunities for teaching  a brand new beginner that will make them better.  Having to explain something at a really granular like specific level to somebody who doesn't  understand the bigger picture is really difficult.  And it's actually surprising how many senior people struggle with that.  So bringing somebody on who's super junior and doesn't have a lot of exposure to these  things is actually really great even if you have a primarily senior level team.  It also brings on a lot of different perspectives and skill sets, especially, I mean, even if  you're hiring from like a traditional CS program, but if you're hiring from like an accelerated  training program or a boot camp, you're going to get all of this like life history and career  experience that is really interesting and kind of exciting.  So it's going to reenergize your team and it's going to bring on a lot of interesting  perspectives and approaches to the work, which is great.  And then you should also just be very clear about how your apprentice's time will be spent  and how they're going to be progressively ramping up so they are able to take on more  and more billable work.  Like there's an expectation that initially you're going to be, you know, not have as  much billable time and then as you taper off towards the end of your apprenticeship that  you should be pretty much mostly billable, right?  So be clear about that and then just have a game plan for how they're going to get up  to that skill level so they are more billable.  So then we have backwards planning.  So this is something around, this is probably something that's going to be happening around  the same time as your team buy-in conversations and this is something that's going to help  you do that, right?  So backwards planning is essentially helping you make a case for why this is doable and  achievable and it also helps you just set up a game plan for how you're going to structure  things, right?  So when I'm talking about backwards planning what I'm essentially talking about is just  curriculum planning.  So it's basically like, so first of all, curriculum is not a scary word, you can do this.  It's basically just saying that you are going to start out figuring out where the person  needs to end up and then working your way backwards.  So at the end of the program they should have this set of skills and I know that and then  how do I actually break that down from day one to make them successful to hit that point  that I need them to be at.  So around curriculum planning, things that you can do to organize this is, so you start  again, like you start with a list of skills and competencies that you want them to have  mastery of at the very end of the program, right?  So you're going to go ahead and make sure that they, you have been very clear and explicit  about that.  So we're basically starting at like the most, like biggest picture view and then we're working  our way into a more granular level.  So again, we start out with like, end of the program, where do they need to be?  Then we work our way out from that, we work our way in from there.  So we say like 10,000 foot view, how do I get them there?  So this is when you start thinking about like if I need them to know this whole big set  of stuff, how do I actually break that down into bite-sizable pieces so I'm not just like  throwing them in the deep end and expecting them to know how to swim them.  I haven't put little like water wings on them at all.  So that's this next step.  Then finally we kind of go down into a week by week breakdown of goals.  So this is when we really start getting granular, we really start breaking this like bigger end  goal down into these little pieces.  And again, this isn't all that different from like project planning, right?  So it's essentially like you are taking this big problem and you're breaking it into little  pieces that don't seem so intimidating.  But again, this is just about education.  So we're dealing with how do we take this larger problem and then we break it down into  little pieces.  So this is going to be something where like you figure out from week one, what do I need  them to know?  And then I'm going to build on that and you're just going to build your way upwards towards  the end of the program.  You also need to understand what success looks like at all of these various stages of the  apprenticeship and then also additionally.  So you need to understand what success looks like and then in parallel with that you need  to understand what kind of a plan do you have if they start falling behind.  And it's likely that they'll have several different things that they need to be working  on at the same time or that they'll be ramping up on and not everybody learns the same skills  at the same pace.  So it could be that there are certain things that they're really excelling at and then certain  things that they're sort of struggling with.  So just being prepared for that and then having some sort of a game plan so you can kind of  hop in and start helping them out if they get stuck.  And then another thing is just to be sure that you have a clear, you have clear ways  that someone can understand what skills they need to know and then how they can improve  on those.  And again to get a whole team buy in it's important that you have set up this information  in a way that is accessible to the whole team so everybody's able to be on the same page  and just be clearly communicating at the same time to both the apprenticeship and each other  about where they are at.  And this is also really helpful because the apprentice can then sort of like self assess  along the way and it's not just totally on you to like have to hand hold them and tell  them where they're at.  So again it also just allows the team to be aligned and you're not getting mixed messages  from everyone.  All right.  So again to understand how to track progress for once your apprentice gets started.  This is something that is a little bit tricky because it can feel a little bit ambiguous  and you've got a lot of different things that you need to kind of pay attention to because  if you like software is not the simple things you need to have there's going to be multiple  things that they're ramping up on at the same time.  And so you need some sort of a rubric that you can like balance against and check against  so people understand where they're at and they have like actionable steps that they  can take to get better at certain specific skills.  And so things that I've seen great success with are when we have like a tiered scoring  system essentially.  So these can be either rankings from like red to green so red would be something that  someone is struggling with in green is something that they're just correct their crews and  they don't need a lot of help with that.  You could have like sort of a number system so one to four or even just something like  from novice to expert.  Right.  So you can just have just some sort of ranking that somebody understands the tiers and like  the structure that they can keep working their way up from.  It should be kept some somewhat simple.  You don't want to get so complex that it's overly tricky to understand or to use.  So I'd say probably between three and five sort of skill levels per skill that they're  mastering so different levels that they can work their way up from.  And it should really have clear and explicit steps that explain how to move forward from  one level to the next.  Something else to consider is just semantics.  Right.  So the phrase things really matters especially when someone's in a situation where they're  learning something new that they're a little bit uncomfortable with.  And it can actually have a really big impact on people if you use poorly chosen words  and you can really negatively impact someone's progress and their growth.  So you don't have to treat them like a delicate flower.  You don't have to be like a really warm and fuzzy about everything.  But it is important to just use language that builds them up rather than tears them down.  So as an example of that, here's an example of some positive language that we use at Turing.  So this is a very high level breakdown of just the language that we use for students  in the first few weeks of Turing.  So you see we have a breakdown from novice, advanced beginner, proficient to exceptional.  We have four levels of skills and then within there, so novice is defined as, and again,  this is very high level.  This isn't broken down into granular sections of skills.  This is just a big picture, 10,000 foot view of how they're doing.  So it says, can function but needs a lot of oversight for novice.  Advanced beginner is can function with very little oversight.  Proficient is can confidently implement code without the need for rigid feedback.  And then exceptional is understands and execute advanced concepts.  So there's a pretty clear progression of skills and understanding there.  And it allows them to, they can go and read this and they don't need us to necessarily  sit next to them and guide them.  And that's really useful because it means that they're able to take control of their  own learning and you don't have to can't hold them quite so much.  Then we have another slightly more in-depth example.  So this is an example for just get how they understand version control.  And again, we have the four-tier breakdown from novice to exceptional.  With novice essentially just saying they can use commits.  They can articulate what a commit is.  So that's good.  Hooray!  And then they also, but they're kind of taking big commits and then shove them all up to  master, which is a little bit of a dangerous game.  And then we take it up to exceptional, which is that they know how to reset to previous  commits, rebase large sets of small commits, and then if applicable, use other advanced  git maneuvers.  So we have a pretty drastic change in their understanding of this specific skill set,  which is really useful.  And so again, you would just sort of break down each sort of step of the skills that  you'd want them to understand in this way so they can go in and self-assess.  And this should be something that is available and accessible to your whole team.  So everyone who's working with the apprentice, everyone who needs to support them and guide  them, so everyone's on the same page and being consistent with the messaging that they're  giving them.  So everyone's just communicating consistently to them.  And they can also self-assess.  So those are things that you should handle before you get a human on board.  So that's going to be something that's going to allow you to be in a good place to just  start working with them once you get somebody on board.  You're going to have all your systems in place, your teams on board.  You have a game plan.  You know where you need them to be.  And then you need to actually find the right human.  So it's not really all that different than hiring for another dev position.  The biggest thing is that you're looking for somebody, you're investing in someone as a  prospect rather than someone with a proven track record.  So it takes a little bit of, I guess, potentially a little bit more finesse than just hiring  someone who you know.  You've seen their work at other companies.  You've seen them speaking at conferences.  You've seen them around.  You've seen their blog posts.  You know what they've been doing and you know they're really good.  This is someone who's kind of an unknown and it's a little bit of a risk.  But there are definitely things you can look for that will be really helpful in guiding  you to find the right person and the right fit.  And that's actually a big part of what I do at Turing.  So a big part of my job is to really just quickly and accurately gauge who has the right personality  or just attitude and perspective to be successful in this type of environment where it's a little  bit less supported and it's something that they can learn on their own and they can be  successful there.  So things that I look for.  So I tried not to use GIFs but I should have put a GIF in here.  Anyway, so something that, I'm sure that most companies have some sort of structure around  how to evaluate people for the role that they're looking to fill and it's super useful to do  that for apprentices as well.  And you also have to just consider like what are your goals for this person?  Like where do you want them to land and what do you actually need them to do?  Like are you looking for somebody who's going to be just a hot shot right out of the gate  that has leadership potential and who's going to make your company and probably your program  just look amazing because they're just really good but potentially you're going to get poached  away for something a little bit more fancy pretty quickly like you never know.  Or do you want somebody who's going to be really solid who's going to just get into  your code base and just learn it really, really deeply and really effectively and be happy  to hang out for a couple years?  Like you understand like where you want this person to go and what they're going to do  for your program and then hire appropriately, right?  So not all personalities are going to fill the same role in the same way.  So things to look for are just like thinking about how they're going to fit in the group.  So there's this interesting idea when you're thinking about group dynamics and you'll see  this a lot in just companies and organizations and it's this like 1080-10 rule which means  that essentially when you have a group of people they'll be broken out into three groups.  So you'll have the top 10%.  These are sort of like the leaders.  These are the people who are, they're going to excel kind of no matter where you put them,  they're really motivated, they're going to push really hard and they really just sort  of are driven to lead.  These are the people who tend, you kind of tend to gravitate to, you're like oh I want  to hire that person but they're also the people who maybe that's not actually what you want,  right?  They're the people who are kind of going to be the movers and shakers and they might  mix things up and change things a little bit.  The middle 80%, these are the people who are more than happy to do the work that is asked  of them, they're not going to rock the boat, they're going to be really consistent, they're  solid, they're really stable and they're going to execute really well and they're consistent.  This is like obviously 80%, this is the majority of people that you end up working with.  And then there's the bottom 10% which are, they're kind of like the dumpster fires that  are cleverly disguised as humans.  So we're going to just assume that you can tell when those people are in front of you  and you're not going to hire them so we're going to focus on the top 10% and that middle  80%.  And again like the group that you want your apprentice to come from really just depends  on what your long term goals are for that person and for that role.  And so you just have to make sure that you're hiring from the right group.  So things to consider when you are looking for your apprentice, that attitude really  counts for a lot.  So I've worked with around 150 people that have taken from like zero to getting jobs  and I focus on the first section of their time at Turing.  So I'm like mama bearing them when they're in their first like, what is happening to  me phases of school?  And so the patterns, I've gotten very good at like noticing patterns and behaviors that  indicate someone is going to be successful in this environment and then which patterns  indicate that somebody might not be.  And people who really excel in these types of situations and these sort of like semi-self-directed  learning environments have a shared set of qualities.  So things that they tend to do, they're very engaged.  So these are people who, they're very curious, they want to go investigate.  If they see something they don't understand, they don't wait for you to kind of give them  a nudge to go check it out, they're just in it.  They start checking it out, they start digging around and investigating things on their own.  And they also, generally because they're really curious and they're really engaged, they find  ways to make it fun for themselves.  And fun makes you learn things better.  It makes you learn faster if you're able to make things interesting for yourself.  It means that learning is going to come easier to you.  They're also loyal.  These are people who like if things get, if things get harder kind of go off course because  this is a business and you never know like maybe you're going to lose a client, maybe  something weird is going to happen, they're not going to, they're not going to bail, they're  not going to freak out, they're going to like, they're going to stay the course.  They're vocal and they're honest.  So these are people who, they're not going to be confrontational and they're not going  to be irrational, but if something is wrong or if they don't like something, they're going  to speak up and they're going to talk to you about it.  You have high standards, they have high standards.  These people are often top performers.  They're used to excelling at things, they understand what success looks like and they  understand how much work it takes to get to that point.  So they understand effort and they understand what it takes to get there.  And then they're dedicated.  So again, if you give them something, they're going to do it to the best of their ability  and they're not, if they get stuck, they're going to ask you for help.  Great.  Obviously like again, when things get hard, they're not going to bail on you, they're  going to keep cranking, they're not going to give up even if things get uncomfortable  because they know that things will get better and that they'll grow.  And then they're just good natured.  Learning is hard, learning the program is hard.  You want to be working with someone who's going to make it a fun experience for you  and for them.  So and then again, like you have that, it's like it's one thing to have like that list  of like what to look for, but then it's another thing to actually be able to like identify  that in a candidate.  Like how do you actually know that they're really like that?  It's very easy for some, I mean some people are really good at just jazz-handsing their  way through interviews and then they show up, show up on day one and you're like, oh,  you are not who I thought you were.  So it's like how do you avoid that, right?  So that's a little bit of a tricky thing.  So it's important to start to think about like how do you separate the people who are  really great from the people who are just really good at interviewing.  So things to look at, their track record, what have they been up to?  Like have they actually shown that they are able to tough out hard things?  When things get hard, do they bail?  Or do they tough it out?  Have they been floating out like as Wayne from Wayne's World says?  He has many name tags and hair nets.  So like you don't want someone who's like that.  You want somebody who's able to show them that they can like hang in there, tough it  out, grow in a role and be there through the hard times and the good times.  Again you want to show that they're able to like tough it out through difficult times.  So this could be shown in a previous career, like whatever that is, I don't care if they  were like an attorney or if they were working as a line cook.  There are difficult things in every job and there's potential to demonstrate that they're  gritty and tough and can handle things in any position they've had before.  Or in school, right?  So like if they were able to deal with a difficult program or just get through school in a way  that is successful, there are many ways that they could show this to you.  And essentially what you're just looking for is that they're able to make steady and consistent  forward progress when they set their minds to doing something.  And then another thing to think about is just how do they like really pay attention to how  they're answering questions.  Again like the jazz handsers, they're going to be trying to like target what they think  you want to hear and they're going to tell you that.  But really, if you pay attention to them and if they're thinking about how they take your  question and they apply it to their own experiences, that's important.  So be mindful if you think that they're just telling you what you want to hear or if they're  actually taking your question and answering it truthfully.  And to help you see if this is what they're doing, you can set up a situation where you're  asking leading questions where you might say like, what would you do and set in an example  situation?  Like if a client calls you and they're really upset about something, what do you do?  How do you handle it?  They might answer, they might tell you what they might do hypothetically and then you  say, like you listen to it, you hear them out and you say, cool, like great, that's awesome.  Can you give me an example when you did that in a real situation?  Tell me when you actually did that.  And someone who actually has done that will tell you about it or that's how they would  answer the question initially and someone who never has and is just sort of like playing  to your question might not have that answer for you.  It's also useful, so something that I've seen, especially with apprenticeships, is that  oftentimes that, like the actual code challenge gets passed over because people just assume  that this person is going to learn on the job, I don't really need to do a code challenge  with them, that's not something that's super important.  But it actually is, right?  And it's less about should I hire this person or not because you understand that they don't  know everything and they may be pretty soft in certain areas, but it's more around just  so on day one when they come in, you know where they're coming from and you know where  their skills are.  So this is just to kind of help you understand what your starting point is.  So yeah, it just gives you an idea of like, do they understand the language, what's their  handle on syntax, do they understand what normal workflow looks like, do they understand version  controller, like how to pair with people, just basic stuff around just experience with  the industry.  And then again, keep your end goals in mind.  So have a plan, like just keep your eye on the prize of like, where do you want this  person to end up at the end of your program?  Do you want them to be a part of your team for a long time or do you want them to come  through the program, be really successful and then like spread their wings and go somewhere  else?  Like who knows?  Be mindful of that and then hire appropriately and gauge appropriately.  All right, so you have done all your planning before you started an apprenticeship, you  have hired the right person, you have a plan, your whole team is on board, so now what do  you do?  Great.  How do you get it all together?  So when you are hiring someone who's never worked in the industry before, onboarding  is a little bit different than someone who understands your routine and knows what to  do with everything.  So it's a great idea to just get some things in place to have one central location where  all of this information is available again to the apprentice and the rest of your team  so everyone's on the same page about things.  A very sort of simple low effort way to do this is to just have like, you can make a  document, you can just like open, you can do something in Google Docs, have some sort  of a calendar or something, or you have all the relevant and important links in one place  so your apprentice can just bookmark one thing and then they have access to everything so  they don't have to chase it all around.  And things that they should, they might need could include what repos they need access to  and then who's going to be taking care of that for them, who's going to actually give  them access to all these things.  Any specific systems set up that they need to have before you get started?  So they have access to all, again, so they have access to this.  They know where to go, they know where to look for it.  Any communication channels that they should have access to before you get started?  You want to, that means like, if it's Slack, HipChat, whatever, make sure that they're  in the main channels that your team communicates with so they're able to hit the ground running  and they're not sort of out in the cold and feeling a little bit ignored.  Any important calendars?  Calendars are great.  That's always important again so you can track timelines.  This is also a place where you can put all of those details around like goals for where  they need to be every week.  That's also great.  And then just directions for how to contribute to a code base.  How does your team follow specific rules?  You can't assume that this person has done this before so it's important to make sure  that it might seem a little bit silly or a little bit obvious, but this is someone who  hasn't worked in this industry before so silly and obvious is okay.  It's not silly.  It's good.  So just any sort of directives around how to contribute to code bases and giving them  enough information that they can kind of dive right in and start taking a crack at contributing.  And then also just if there are meetings like stand-ups, team meetings, staff meetings,  whatever, make sure that they understand when that is so they're able to go to that when  they need to.  It's also important to have a syllabus and a schedule.  So again, calendars and then some sort of a structure for your curriculum.  Again, this is all about communication and your calendar is going to map out expectations  and timelines that are going to allow your apprentice to have a clear upwards trajectory  of skills and progression that you expect them to be hitting.  And this is something that is going to just allow them to so they can keep track every  week as they're working.  So for your syllabus, again, it's your learning goals for every week.  And it gives the apprentice a place to see where they're headed and what they need to  be focusing on.  That could include like a list of useful resources.  So if there are tutorials, documentation, things like that that would help them get  hit those goals for that week, that's a great place to put it.  Assignments.  So we'll talk about what that might look like in a minute, but you could potentially have  like assignments that they could be working on.  So outside of just like teamwork or like billable work, they could have things that they're  actually working on to like just keep improving and then checks for understanding.  So ways that they can actually confirm that they're learning what they need to be learning.  And this just takes some of the mystery out of the learning process because again, it's  very explicit and it's very clear and it's giving them a clear path forward with a clear  like upward trajectory of steps and that they should be taking.  Okay, so again, during when we are evaluating progress, this kind of comes back to that idea  of that rubric that we talked about a little bit from like novice to exceptional or one  to four, those kinds of ideas.  It's important to understand that you have a way to track that they actually are making  the progress that you need to be making.  So if we consider our evaluation rubric again, this gives us clear actionable documentation  of like what understanding and progress looks like and it allows them to keep up a steady  upward trajectory of progress as they keep working through the program.  And then again, like for the actual sort of like assignments or things that they can be  working on as they're growing and learning, this idea of a breakable toy is really useful.  So this is essentially like a little project that's owned by the apprentice.  It's a code base that's just fully owned by the apprentice and it has a lifespan that's  the length of the apprenticeship.  And this is an interesting idea because it allows you to, it's non-billable code, it's  owned by the apprentice and it allows them to have a thing they can break without worry  that they're going to like break an actual production code base.  And it's also something that you can strategically just match learning goals with like features  that you're having to build on this breakable toy.  It gives them space to kind of get goofy and weird and have fun with it.  So it allows them to have the freedom to sort of play with their code.  It allows them to like kind of pick a topic or something around about the project that  they're really excited about and want to like play with.  And that can be something that like trickles upwards into the rest of the team.  Having fun and just building things because it's a fun project is really great.  Another thing about this is it is really fun.  You can just get weird with it and have fun.  So one of the ways that, again, learning happens the most when you're in a place of just goofing  around and having fun with things.  So this is a great place to like fight through the hard problems because it's a project  that's like a little bit of, it's just, it's near to their heart and they just really care  about it.  So something silly where they don't have the pressure of the actual client work is important.  Something to keep in mind.  An apprenticeship should be a safe place to fail.  Learning is part of learning.  Like when you're learning to ride a bike and you first take the training wheels off and  you realize that you have to think really hard about riding the bike and staying on  the bike and then you're going to fall off the bike a lot with that point.  The more you're thinking about it, the more you're going to fall off of it and that's  okay.  And then gradually you realize that you have to think about the bike less and then eventually  you realize that you're not thinking about the bike at all and you're just getting on  the bike and riding away.  And that's okay.  If they fall off the bike, if they break things, that's okay.  It's the same deal with software is riding a bicycle.  You have to just encourage them to keep getting back on the bike and you have to let them  break things.  Don't make a huge deal out of it, but let them know that they did it and then make them  fix it.  Don't fix it for them.  Don't follow them around.  They're not delicate flowers.  They can fix it themselves.  Be supportive and then help them when they need it.  And again, as you move forward, they should be able to do that with less and less and  less hand holding.  And then what do you do if the worst happens?  Let's say you get started.  The team was really into it.  You found someone you thought was going to be a really great fit and then things start  going sideways.  Maybe you realized that this person you thought was going to be a great fit, maybe isn't meshing  them with your team, maybe they're not learning at the rate that you needed them to.  There could be many things that are happening that aren't, I mean, that this isn't going  to work out.  Just be honest and upfront about it.  Things that I've seen happen sometimes is that apprenticeship programs can get dragged  out well beyond their useful lifespan.  And that doesn't do the team any favors.  It doesn't do the apprentice any favors.  They probably know that they're struggling at that point and keeping them around in that  way isn't really doing them any favors.  It's not kind.  So it's better to just call a spade a spade if it's not working out.  It doesn't mean that they can't do this.  It probably just means that this isn't the right fit for them.  Or maybe they're okay, but you ran out of money.  Like, that could happen too.  Maybe you lost a big account.  Maybe you lost a client.  Maybe just the business, just something happened to the business and you lost users or something.  That's okay.  That happens.  But never put someone, especially an apprentice, don't put someone in a position where you  can't pay them and you want them to work for experience.  So if you get to a point where there is not money for them, again, cut them loose.  Let them know what's happening.  Keep them in the loop and then cut them loose.  And the thing is that bad things happen.  It's okay.  Just be fair and be honest about it and really do your best to set them up for success.  And try to help them land on their feet.  So the way that an apprenticeship ends, whether it's the happy path where you now have a new  junior dev on your team who's just crushing it and kicking ass and doing everything perfectly,  or you have someone who just didn't work out for whatever reason, the way that that ends  says a lot about your team.  And if worst case scenario happens and it's not working out, the way that you handle that  and if you're able to end on good terms with this person and support them and really still  try to help them land on their feet speaks very highly about you and your team.  So again, just make sure that you are being respectful and kind for everything.  And then I just have thanks to people who have helped me.  And then, yeah, some resources.  That's it.  Thank you.  For self mentorship.  Okay, so the question is how would you adapt this advice for self mentorship?  There are actually several, there are some great apprenticeships that have sort of like  open source curriculum that they set up.  There are also some schools that have like their curriculum that's online.  Sparkbox has a really great, they have a really, like if you go on GitHub and just like Google  Sparkbox, you can find them.  They have a very like clear, direct, just like curriculum path for their apprenticeships  that has lots of like tutorials, lots of like documentation, lots of things like that around  there and then there's also various schools and things.  So a lot of it's the same thing.  Like you figure out, it's like that backwards planning is super valuable.  So if you think about where you want to land and just start like working, like figuring  out like from where you want to be and then taking small steps forward, does that answer  your question?  Yeah.  Okay, so the question is what is sort of like thoughts on taking an apprentice cohort rather  than having them working together rather than having individual apprentices sort of like  dividing, conquer, solo on side projects and things.  I think that there's a lot of value in having like your battle buddies, right?  So it's the same thing like in school.  Like you have a group of people, you have a cohort that they're there to support you.  They're there to bounce questions off of their people who are at the same, a similar level  to you.  So maybe you don't feel quite as self-conscious if you get stuck on something that you think  might be a little bit silly.  I think that there's a lot of value in that.  I think there's also value in kind of just if you're like, if you're in a program that  only has one apprentice kind of being like the only person there, like the lone wolf,  there's also value in that and having to just sort of get in there and just force yourself  to talk to the senior people who might be intimidating.  But I think they're absolutely, if you are in a position where you can have a cohort  of people who can like support each other, I think there's a lot of value in that.  Sure.  Sure.  Okay.  So the question is like how do you sort of keep your bias, your sort of like internal  biases from impacting the way you're hiring decisions, even if like some of the things  that you're sort of hiring for tend to maybe be a little bit more generally considered  like masculine.  So I think something to consider with that is, and part of that is just like the interview  process and setting this person up to feel like comfortable in that.  And you'll find that it's interesting because like we see this also in our interviewing  students as well.  You'll have people who come from these not like non white guy backgrounds and they'll  come into the interview and they'll sort of start out with the normal like maybe I'm  a little bit more quiet, a little more reserved and then you start talking to them and you  ask them the right questions and you realize that like they're crushing it and they're  amazing and that they're super smart and they're really good and they have opinions and they're  able to do these things.  And I think a lot of it is just setting up the interview process in a way that allows  people to have room and space to tell their stories really effectively and to be safe.  So some of that is just forcing yourself to make sure that your interview process is structured  in a way that you're not intimidating people, you're not making people uncomfortable.  It's also about outreach as well, right?  So making sure that you are like getting word of your apprenticeship out there so people  who are maybe from these different more diverse backgrounds know about it and they're able  to talk to speak to it or to see it and apply for it.  Does that answer your question?  Yeah, so I think absolutely the expectation should be set that in the beginning of the  oh sorry, so the question was just like the balance of like billable work versus non billable  work during the course of the apprenticeship.  Is that correct?  Okay.  So, yeah, so if we're talking about, so billable work, so first just what I mean when I say  billable work, like when you're on the job, when you're going to like your time sheet  and you're putting in what I did today, billable work would be the things that are actually  the tasks that you've done that are allowing the company to make money.  So that could be like actually pushing production code, like doing things like that, things  like meetings or like internal meetings or like reading documentation or doing tutorials  or something like that, that's non billable.  But like actually like writing production code and like pushing that up and getting  that live, that's all part of like your billable hours.  And as an apprentice, part of this role and part of this job is that you are learning.  So what it should be that in the beginning, your hours are skewed more heavily on the  non billable side.  So you're working on like your breakable toy project.  You're working on something that isn't necessarily contributing to the inflow of cash to the  company, but you are still growing and you're still learning really well.  And so, but the idea is that in the beginning, you're going to be learning, you're going  to be ramping up and figuring all this stuff out.  And then during the course of the apprenticeship, you should be that ratio billable to non billable  should flip and you're going to be having almost basically by the end of it, you should  be at sort of like normal billable hours for a junior dev.  So whatever that breaks down to for that company, so I'm not sure like what percentage that  would might be per company, but like there are certain sort of like acceptable amounts  of hours that should be billable.  So you would want to by the end of it, the idea would be that you'd be at that point  and then you'd have less time dedicated to like learning and that sort of thing.  And then in the beginning, it'd be much more heavily skewed towards learning.  Did I answer your question?  Cool.  Any other questions?  All right.  Thank you so much.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thanks everyone.  Take care.  Thanks MissIFJ.  Oh, man.  Thanks.  Thank you.  Thanks so much.  Thank you.  Thank you.  Thanks.  Thank you.  Thanks.
Great_Expectations_0_47.png Great_Expectations_48_131.png Great_Expectations_132_287.png Great_Expectations_288_551.png Great_Expectations_552_695.png Great_Expectations_696_1079.png Great_Expectations_1080_1295.png Great_Expectations_1296_2039.png Great_Expectations_2040_2531.png Great_Expectations_2532_7847.png Great_Expectations_7848_8159.png Great_Expectations_8160_11915.png Great_Expectations_11916_16859.png Great_Expectations_16860_32399.png Great_Expectations_32400_33287.png Great_Expectations_33288_39227.png Great_Expectations_39228_44351.png Great_Expectations_44352_46427.png Great_Expectations_46428_48083.png Great_Expectations_48084_58139.png Great_Expectations_58140_59519.png Great_Expectations_59520_59939.png Great_Expectations_59940_60539.png Great_Expectations_60540_61211.png Great_Expectations_61212_68519.png Great_Expectations_68520_68819.png Great_Expectations_68820_68867.png Great_Expectations_68868_69131.png Great_Expectations_69132_69239.png Great_Expectations_69240_69455.png Great_Expectations_69456_69563.png Great_Expectations_69564_69671.png Great_Expectations_69672_69995.png Great_Expectations_69996_70091.png Great_Expectations_70092_70247.png Great_Expectations_70248_70391.png Great_Expectations_70392_70439.png Great_Expectations_70440_70547.png Great_Expectations_70548_70763.png Great_Expectations_70764_71123.png Great_Expectations_71124_71291.png Great_Expectations_71292_71351.png Great_Expectations_71352_71447.png Great_Expectations_71448_71603.png Great_Expectations_71604_72107.png Great_Expectations_72108_72599.png Great_Expectations_72600_73055.png Great_Expectations_73056_74159.png Great_Expectations_74160_74219.png Great_Expectations_74220_74363.png Great_Expectations_74364_74411.png Great_Expectations_74412_74567.png Great_Expectations_74568_74627.png Great_Expectations_74628_75335.png Great_Expectations_75336_75395.png Great_Expectations_75396_75527.png Great_Expectations_75528_75611.png Great_Expectations_75612_75767.png Great_Expectations_75768_75947.png Great_Expectations_75948_76127.png Great_Expectations_76128_76235.png Great_Expectations_76236_76295.png Great_Expectations_76296_76343.png Great_Expectations_76344_76559.png Great_Expectations_76560_76871.png Great_Expectations_76872_77291.png Great_Expectations_77292_77387.png Great_Expectations_77388_77531.png Great_Expectations_77532_77572.png