What's the real difference between a junior developer, an intern and an apprentice?
Case Studies in Apprenticeship Vol. 3 — Amelia Padua
Time to Read: 11 minutes
Joe: Thank you, first of all, for sitting down and taking the time to talk.
Amelia: Thanks for having me.
Joe: Just to start out, tell me a little bit about yourself. What your experience is, how you came to be associated with this apprenticeship program.
Amelia: So I… I’m trying to think how far back I should go. I’ll start with Dev Bootcamp. I did work as a developer a little bit before Dev Bootcamp, but I wasn’t gaining enough experience as a developer at my job at the time. So, I went to Dev Bootcamp, built up more industry knowledge, and I was able to reach out to Trunk Club. I originally was applying for an internship, because at the time they didn’t have an active apprenticeship program. But through talking to Mike Cruz, VP of Engineering, he kind of brought up the idea of an apprenticeship as opposed to an internship. I thought that sounded great, and so I said “absolutely, of course!” *laughs* Like, I’m here for the first thing, but I’ll take the second. So that’s kind of how it started, mostly through a conversation with Mike.
Joe: Trunk Club had an apprenticeship before that, though, right, prior to your coming on?
Amelia: They did, yeah. Our first apprentice, Jean started about two and a half years before I started. But there were only like four or five engineers at the time, so according to what I’ve heard, it was a very different company.
Amelia: They were just starting out It seemed like he was just kind of getting in there and doing everything he could to help out in a lot of different areas. When I came on I think they were looking to make it a more formalized program. But Jean blogged a little more than I did. He blogged.
Amelia: I think when I started, since there was this bigger company, they tried to create more structure around it I think.
Joe: So tell me a little bit more about that. What was it like being an apprentice for Trunk Club.
Amelia: It’s a six month program, give or take. My colleagues always like to say that it’s up to the person. So if it takes a little less time, that’s fine. That’s great. But if it takes a little longer, that’s fine too, as long as there’s some progression happening.
But in general, it takes six months. We have a review every two months, just to see how things are going, give any feedback on both sides. We want to hear how the apprentice is doing, how the apprentice feels like the program is helping them, and so on. They start on a team, and as they start learning more about the company, after a month or two they come up with an idea for their own project. They spend the next four or five months working on a project that they champion and get other people excited about, and they work right away to get this idea into production.
Joe: So when you’re on the team are you mostly assigned bugs and learning on your own, or is it more formal education? What does that look like?
Amelia: For me it was a little different than the apprentices now. We’re still figuring out ways to improve. When I started, we had a couple people who would rotate every couple of weeks from their normal team to a special team that would be the first line defense for bugs. And so I was helping them, bugfixes at first just to get to understand the system better. And then, after a couple weeks of that, it got into “here’s a story that you’ve seen bugs leading to so try to jump into that.”
Joe: Oh, okay. So you were taking the little bug you did and expanding on it to make a larger fix.
Amelia: Right, exactly. If possible. It didn’t always line up.
Joe: That’s one of the hard parts about using real bugs.
Amelia: Yeah. So then you get a card and you take as much time as you need to complete it. There’s no “get this done by tomorrow”. And I think the goal is to try to do as much as you can on your own. Read some code, try to figure out what’s going on, but at some point you should ask for help.
So it’s kind of ambiguous. It’s different for each person, but we’ll guide you to the next step.
Joe: So the resources you were talking to for help. Who were those people? Is it the bug team?
Amelia: At first it was, because those are the only people I knew. *laughs* But after a while, you kind of learn who to ask. Slack becomes your very good friend. You ask a question in the right channel, if it pertains to a certain team. And generally you’ll have a couple people jumping up saying “hey, I know this pretty well, I can help you”. That’s how you get to know a lot of people; you just ask a question and somebody will help you.
Joe: Yeah, usually there’s some expert for the system who’s like “yeah, I wrote that.” It’s a good way to start.
Amelia: Yeah, exactly. You meet a lot more people that way.
Joe: You said that the original person who had come on as an apprentice did some blogging. You didn’t, and I didn’t make my apprentices either. Is there some kind of outlet where you can really put the stuff you’ve been learning?
Amelia: I was going to say, we definitely encourage to blog if possible, but it’s not a requirement. It’s hard.
Joe: Yeah. I always want to encourage people to have a journal at least. Even if it’s not released to anybody else.
Joe: We had Slack as well, with a private room for the apprentices, so they were a little less afraid of being seen not to know what they’re doing. It was super helpful.
Amelia: We have that too! It would have been great to have that when I was an apprentice. I had my own journal where I would write things down, but he apprentices now communicate and share a lot with each other in their own channel I think we currently have one. We had four at one time.
Joe: Okay. How many have gone through the program?
Amelia: I think it’s been about five people, other than me. Or maybe five including me. Around there. So they have their own channel, and they actually take it upon themselves to do lunch and learns.
Joe: Oh cool.
Amelia: And they decide “hey, I’m going to present on whatever topic, or get somebody from the team to present on” some topic they’re trying to learn. So they’ve been very proactive about figuring out how to spread knowledge, or ask for help. The apprenticeship channel is really active. There are a lot of setup issues like Docker.
Joe: There are a lot of setup issues with Docker. *laughs*
Amelia: *laughs* They’ve learned how to ask each other for help with that, and it seems to be where they go first and then they ask the team.
Joe: Are those lunch and learns with the whole organization or inside the apprentices?
Amelia: Most of our things are for whoever wants to come, but it’s usually geared towards apprentices.
Joe: Cool. You started with one person in the apprenticeship with five engineers. Now you have three or four apprentices. What kind of challenges have you found in that process, especially as you end up with more apprentices?
Amelia: I think the way we bring on an apprentice helps to mitigate some of the issues with having too many apprentices. We only bring on an apprentice when we have an engineer that volunteers to take them on. Or they say in an interview “I would like to take them on”. So they take that person under their wing, and we have plenty of work for people to sink their teeth into.
Joe: Yeah, not running out of work. *laughs*
Amelia: Basically, yeah. *laughs* It can be challenging,especially if you have a deadline you have to get through. You don’t want the apprentice to have to hastily work on something they don’t completely understand. So there is a balance.
Joe: And you had mentioned before the capstone projects. Which sounds like it has challenges of its own.
Amelia: I think that is the coolest and most challenging part of the apprenticeship program. The coolest thing is being able to come up with your own idea, you talk to all the end users, figure out a strategy for completing the project. And then it actually ends up in production and you see people in the company actually using what you’ve built, it’s kind of amazing.
The challenge with that is that you spend half of your time working on that, and half of your time on the team stuff. And it’s very challenging to stop what you’re working on, and switch gears. It’s rough. I think it’s rough for anybody, but especially somebody who’s just starting out.
Joe: Definitely. When you don’t have confidence in your abilities, and you get stuck on a bug, it’s hard to just stop working on it anyway to do something else.
Amelia: Yeah, right. I think it happens a lot. Especially, it happened to me a lot. Instead of half and half in one day, you’d spend a day or two on one topic, and decide to spend a day or two on the other side of the work.
Joe: That’s a great idea.
Amelia: But everybody struggles with that time management thing.
Joe: I think
Amelia: *laughs* Yeah. And then after a couple sprints, you realize “oh I should have spent more time on this thing, or I should have spent more time on this other thing”. It’s still something we’re trying to figure out I think.
Joe: Cool. And it’s nice because the capstone is still something that’s going into production. So it’s not a “waste” of time, per se.
Amelia: No. Hopefully not! Hopefully you made a difference.
Joe: So, are there other effects you’ve seen from having the apprentice program around, on other engineers?
Amelia: Yeah, I think something that happens is you have a few people looking at a piece of code, or a process, and then other engineers have to be able to explain what’s going on. And if it seems kind of crazy to who you explain it to, then maybe we should rethink how that’s going. And that’s happened a couple times. Just recently, one of our interns asked “why are we doing it this way? This seems really complicated.” And we took a step back and realized it was a little too complicated, and we needed to rethink it.
So having fresh eyes.
Joe: Right on. That’s all I’ve got for questions. Do you have any kind of final advice for companies that are potentially trying to start a program but are a little scared?
Amelia: I think the biggest fear is that you’re pulling someone along, as opposed to somebody’s helping you out. And I think I would see that person less as someone who’s going to produce lots of features quickly, and more as someone to help you look at your code and processes with a new perspective. And by the end of that process, your code will be better. And they’ll have the context to jump in and help out and continue your work.
Joe: Awesome, thank you very much!
Amelia: Thank you!
haiku can be fun but they don’t always make sense refrigerator