Case Studies in Apprenticeship Vol. 6 — Mike Jansen

Time to Read:

Joe: First, thanks for taking the time to talk to me about your program.

Mike: Yeah, it’s a pleasure.

Joe: Since you’ve been at this for so long, could you tell me how you got involved with the 8th Light apprentice program?

Mike: So, I guess I got involved when I joined the company. I came to 8th Light when we were maybe fifteen people. This was early 2011, and we had just opened up our Chicago office downtown. I was working at a medical software company, Epic, up in Madison, Wisconsin and was programming, but I was also doing project management and technical support. We moved down to Chicago, I wasn’t quite sure what was next for me.

With my contract I had about a year of a non-compete, so I couldn’t stay in the same career path, so I was contemplating. Should I go back to school to get a formal CS education, which involves spending money (which I wasn’t a huge fan of)? Or what else is out there? Something I can learn on the job, sort of grow with the other skills that I had. I had background in support in software, debugging software, writing software, but not very formal in terms of the depth and breadth of knowledge.

And I talked to 8th Light. I had all this experience in supporting other systems, and just sitting down and observing those best practices in clean code and test driven development, and it clicked. Within fifteen minutes I was sold on it. I decided that this was the way I was gonna write software.

So I got an offer for an apprenticeship, which was about five months long. For me, I think that was the right amount of time. I had enough time to learn how to write clean code, and how to test drive my code well enough to join a project with a team of software craftspeople. From there, I was off running. I started working on projects, I took an apprentice of my own for a couple months. And at that point, we really started to grow the company by leaps and bounds. That year, we took another ten or fifteen apprentices. In the four years since we’ve grown from fifteen when I joined, to about eighty-five now. Across not just Chicago, but London, Los Angeles and New York.

Joe: Awesome. And, I just wanted to point out that, you’ve mentioned in the past that everyone comes into 8th Light via the apprenticeship.

Mike: Yeah, this is something that is personally important to me. I had a lot of experience coming in, but even if you have a lot of experience writing software for other companies, it’s important to understand how to write code the 8th Light way. One of our biggest strengths as a company is that our teams are focused on writing clean code, they’re focused on product delivery through that mechanism, and understanding what you’re getting yourself into is really important, so you know what kind of code we write.

We always have that consistent experience with our teams. So you can switch teams, and it’s only the domain that changes. The practices are still the same. You can rely upon your teammates to have the best interests of the code base. Versus them trying to play, y’know, we don’t have any hero coders here. And we’ll work hard to get the job done, but it’s about the project, not their own ego.

Joe: What kind of resources do they get as apprentices? What kind of stuff are they working on?

Mike: So yeah, the current structure is really to have a mentor and what we call a co-mentor. This is someone who maybe just finished the program themselves. We certainly subscribe to the idea that having a smaller skill gap can be very valuable, because that person can relate to the person they’re teaching or mentoring a little better than someone that’s got years and years of experience. So that mentor/co-mentor balance has been really valuable for us, and it’s a consistent part of the program, even though four and a half years ago, it wasn’t part of mine.

So as far as what the apprentice receives, we have a list of skills — a bit like a syllabus, I suppose — of the areas to cover in the apprenticeship. It includes test driven development, design patterns. Working in at least three styles of languages — dynamic, static and functional — as a way to understand the different paradigms that exist. Even if you don’t end up writing Clojure day to day, understanding immutability well has a really positive influence on the OO code that you write.

And it’s a pretty fast pace. We’ll go through some typical exercises, some solo projects you can work on. That gives them practice at delivering in a regular fashion to the customer — their mentor — and then some deeper dives. You know, the HTTP server project is a hallmark of our apprenticeship program, because it’s a big enough problem that you can’t just power through it. You have to understand the domain, and go back and implement the right patterns in order to make it sensible.

Joe: There’s an interesting line between that and, say, toy projects where you can get it as wrong as you want, but you can finish. This is a problem where, if you get in enough trouble, you can’t power through.

Mike: Yeah, with one of our apprentices (now a craftsman), he did a really good presentation about it. He said it’s a project where it’s a really good idea just to restart from scratch about halfway through *laughs*. Because you’re trying to test drive, you’re trying to recall the best practices, but you don’t have any idea what you’re doing, from the time you start on it, so it’s really -

Joe: So you spike the first half.

Mike: Yeah, it’s spiking, but without knowing you’re spiking. I think it helps us emphasize the really important parts of the way we do work, too, that you can’t get attached to your code. If you start getting emotionally attached to your code, you lose a lot of time. That’s really bad. That’s not going to manifest itself until you’re doing a project and pushing against a deadline.

And that’s the sort of one way our apprenticeship has a common format. In other ways it’s pretty loose. I say that everyone’s apprenticeship starts the same on day one, and by day two it’s totally unique. It’s about what the person needs to learn at the time. We have an opportunity to keep layering information on top of other information. Maybe in a CS program, you’ll get courses and chunks, and all contained to themselves, but they don’t really build upon one another. We try to layer as much in, as far as project delivery, programming, best practices throughout the project, and throughout the apprenticeship. So it’s never just one thing that you’re learning. It’s always a number of lessons.

Joe: That makes sense. Do the mentor styles end up bleeding over into the apprentice’s style?

Mike: Yeah, absolutely, I mean, we have some mentors that are more into working with Objective C, and Swift and mobile development. They use that as a way to build up some project, or you’re building up your HTTP server. And now you need to have a layer that your mobile application can talk to, or query some kind of data. You start to understand the idea of services more clearly. What should be in your mobile client, versus some service somewhere.

That affects someone’s experience working on projects. what kinds of things have I screwed up? What have I benefited from in project work that I want to share before someone starts some project work themselves? For myself, I know from leading projects that punctuality is very important. That overcommitting is going to put you in a really difficult spot. And so from the very beginning, I will challenge my apprentices to always keep to their commitments. But I also know that they’re going take on more than they can deliver in a week’s time. And there’s no changing that.

So I’ll let them keep on committing, and I’ll keep on asking for more things as the client. And they’ll keep saying yes, but eventually they just can’t deliver it all. And then we’ll talk about it. You know that you can’t get this done, so why did you overcommit? Now you put yourself in a position where you’re behind schedule, and you have to build back credibility with that client.

And so it’s easy during the apprenticeship to switch between mentor and client in those meetings, to be very intentional about, imaging this is a client, and you just overcommitted by half, versus saying what you could get done, delivering, and having that constant credibility of “what I say will get done, will get done.”

Joe: That makes a lot of sense.

Mike: That’s an example of how my experience as a craftsman has impacted my mentoring style. Every apprentice learns about over-committing, but when I mentor an apprentice, I tend to emphasize that very early in the apprenticeship.

Joe: That’s interesting. It’s been consistent that it’s not just technology skills, it’s not how you use Rspec. It’s about that software craftsman. Which is probably harder than other languages we’re actually learning.

Mike: Yeah, I mean it’s, yeah. *laughs* We’ll keep the topic on apprenticeship, yeah.

Joe: *laughs* Different rant for a different day. Are there any big changes you’ve made over the last handful of years, that you might not have anticipated up front?

Mike: Well, the explicit shift to co-mentoring is a very noticable change, and a very positive one overall. I forget even how it happened at this point, but one day, everyone’s doing it. And so we started planning for that.

And at the end of the apprenticeship we have a review process, where someone can demonstrate what they’ve learned. We’ve also learned to be very explicit about checkpoints throughout apprenticeship, where you’re demonstrating what you’ve learned, and that also serves as a really excellent time for feedback, not just for mentors involved, but from other craftsmen too.

Joe: There’s a demo to a larger group of people?

Mike: It could be a demo, it could be a talk, some presentation of knowledge. In software that could be through the code itself, through looking at the git history of how the code’s evolved over time, looking at pull requests and the comments on it. It could be, though, how well does someone write about what they do? Can they communicate their knowledge well? Those things are just as important in a team setting, and with clients, as the code.

Joe: In the other direction, having what is the most successful apprenticeship — at least that I’ve ever heard of, I don’t know if anyone else has done more than 85.

Mike: We’ll just say that’s true.

Joe: *laugh* Where do you go from here? What are you looking towards in the future of the program?

Mike: When it comes to “apprenticeships” more traditionally speaking, an apprenticeship isn’t something that you learn in a year, and then that’s it, you’re done learning. Apprenticeship can be seen as a seven year process. We’ve been thinking about how long it really takes to master all the different components of a job. There’s a lot to learn across a lot of fields, and it would be arrogant of us to assume that we could teach that all in twelve months’ time.

I think as a company, what we’re trying to do is constantly push out this path of shared knowledge, so we can have a seven year continual learning plan. Maybe it’s not called an “apprenticeship” once they become a software craftsperson at 8th light, but it’s still being very intentional about these things. Learning to specialize in some specific areas, versus learning more generally.

You’re gonna have these long loops. You can learn a lot very quickly in 6–12 months, but it can take you years to learn some things really well. It’s about how we sequence these things, how we provide those opportunities, and how we continue that process. So that it’s not just sort of leaping from a very structured environment to one that can feel very open ended. And so part of that we’ve just been doing for nine years.

We believe that no matter what the core components are having a team that cares about what they do, and being surrounded by colleagues that want to do the same kind of job that you do. That itself is about 75% of it, but that other portion is really important, and so we’re constantly reevaluating how to best provide that structure, and opportunity and resources for people to continue to grow over time too.

Joe: One other question. The purpose of these interviews is to help companies that feel a little bit nervous about starting an apprenticeship. Is there any advice you can provide for a company in that spot?

Mike: If you join a team of developers and it’s not clear what they value — what their coding style is, what’s important to them — it’s truly hard to communicate that to someone who’s coming in fresh to the organization. If you’re looking at starting an apprenticeship program, it’s your chance to now impart your knowledge and ideas of what you think good software could be. And if you can’t communicate that internally, then how do you expect someone that’s coming in new to understand that implicitly?

Joe: That’s fair.

Mike: I don’t think that it has to be an immutable codification of values. We’ve got people that worked on the Software Craftsmanship Manifesto, and we have our principles on our website, but these are changing things.

We constantly reevaluate this. If you can, as a team of developers, communicate amongst each other what you value, what you want, what’s important for someone else to learn when they come in, that’s gonna be a real advantage to having someone come in understanding what it is your team does, in addition to learning all the things they need to know about being a good programmer.

Joe: I imagine it would be good for the rest of your team to understand that too.

Mike: Absolutely, yeah.

Joe: Alright! Great, thanks so much.

Mike: Yeah, thank you.