I've been working with apprentices since the early 90s, but I haven't really written about it here; I suppose it's about time!

Every year or so my apprentice graduates and I hire a new one. I recently went through that hiring process, and I'm always a little overwhelmed by all of the interested (and interesting!) people. It's distressing that I can only hire one, especially since I seem to be one of the few people offering this sort of thing in the web development industry.

Anyway, a little history… I started programming when I was 9 and went pro when I was 17. I became obsessed and didn't take care of my body, and by the time I was 20 I had developed a chronic wrist injury that I still have decades later. Maybe I should have walked away from computers, but by then I was hooked! That was a dark time, but eventually I struck upon a solution… I could dictate my code to someone else who could be my hands. Turns out this can be very effective and rewarding (even if it does require some patience).

I use the term apprentice because they're never just a typist… It's impossible to be the conduit for all of that code without picking up a lot of things along the way. I liken it to learning a foreign language by going to a foreign country and hearing people speak it all day long. As we work, I try to explain things along the way, and encourage my apprentice to ask questions. At the beginning I may have to spell everything out, but over time the apprentice picks up the patterns and I can speak at a more high level. The more they understand of what we're doing, the more powerful a team we become!

When I started doing this in the early 90s, pair programming wasn't a widely known practice, but nowadays it's much more common. What I'm doing with my apprentice is much like pair programming, except that the experience gap between my apprentice and me is wider than for most pairs (sometimes my apprentices start out knowing nothing about programming, though that's rarer these days with all the online code learning resources), and we never swap who's typing. Many of the benefits to pair programming still apply:

• Two pairs of eyes on the code means fewer mistakes
• We are focused on the job all day long; having someone else there makes it harder to procrastinate
• Knowledge exchange; my apprentice is learning from me, and I'm learning from talking things through with them
• We are able to discuss design challenges and alternatives to come up with better solutions

You might think all of this communication must slow us down, but quite the contrary… When we get rolling we really fly! Two minds are better than one.

It's a very close working relationship… We sit just a few feet apart and talk constantly together all day long, week after week. Many of my former apprentices have become lifelong friends of mine. It's also very satisfying to see their careers develop after they move on to the next thing.

Often people ask me about my "apprenticeship program" and how they can replicate it at their company or in their region. First off: yes, you should! There are tons of promising novice programmers out there who just need a bit of guidance and an opportunity to grow. There seems to be no shortage of software jobs, but it's difficult for someone new to break in. Anyone who can tap into that budding talent gets a competitive advantage. Meanwhile, the apprentices get a head start with invaluable learning by being directly involved with real projects. Better training and knowledge exchange means better developers, which means a better industry. For more thoughts on why (and how), see Software Training Sucks: Why We Need to Roll it Back 1,000 Years from Rob Walling. I've also written about the benefits of apprenticeship culture before.

I think what I've been doing gives pretty good results, but of course it's also tuned to my situation… After all, the driving need here is for me to be able to get my work done. If I didn't need them to type for me, I would want the apprentice to move to greater levels of individual contribution gradually over time. As it is, I do recommend my apprentice use their off time to focus on their own projects and bring them in to discuss with me, to help cement their learning.

Anyway, my recommendations:

• Pick someone who shows promise and passion but doesn't have a lot of experience. Don't just go for college students on break (like many internship programs), or you'll miss out on all the folks coming out of boot camps or who've learned with online resources. 
• Get them working on real projects right away (whether this be in a company setting or on open source). Real projects are the only way to turn theory into skill. The sooner they get started, the sooner all of the lessons and exercises they've done will actually make sense. Besides, this way they're being productive from the beginning.
• Start them out pairing with someone who's already established. Make sure the mentor/apprentice relationship is explicit and that both sides understand what's expected. I think it's good for the less experienced programmer to do the typing, because otherwise it's easy for them to zone out while the more experienced programmer whizzes around, but your mileage may vary. It may feel slow at first, but you're sharing valuable information, and things will speed up as your shared experience grows. 
• Next step would be to have them make their own pull requests and have the experienced programmer critique them. This exercises different parts of the brain than the pair programming, and helps them move into the driver seat. Actually, I suppose you could do this step live, with the more experienced programmer doing the typing based entirely on dictation from the apprentice, but giving feedback along the way. Either way, you'll already have a rich shared understanding to build on.
• Move them gradually up to more levels of autonomy, until one day they become the mentor for the next apprentice!

So that's my story, and some thoughts on bringing apprenticeship to your neck of the woods. I know it's already happening in some parts of the industry (within companies and at places like Apprenti), but I think it would be great for there to be more of it! Any skilled trade with a complex set of tools and a rich culture can benefit from the kind of cross-pollination and dialogue engendered by apprenticeship, and I'd say software development certainly fits the bill.

What do you think? I'm sure I've just scratched the surface… Hit me up with questions if you've got 'em!

Labels: apprenticeship

A number of years ago I put my tech career on hold and spent some time in Hollywood. I dove in without any formal training and worked my way up from Production Assistant to Grip to First Assistant Director in about a year. I learned an awful lot in that time!

You can do this with filmmaking because of its built-in apprenticeship culture. Making a movie is a real-time collaborative process, so if you don't know what you're doing, there's always someone nearby who can show you the way — all you have to do is pay attention. There are constantly new people coming into the industry, so before you know it you're the one passing on sage advice to the next generation.

This last year, I did a similar thing at Mozilla. When I started working on Panorama, I knew nothing about the Mozilla technology stack, the culture, or what it takes to be part of an open-source project of that size. A year later, I had learned a ton and was already leading others.

It took me a while to identify the feeling I kept encountering during those early days at Mozilla, but I finally recognized it: it was like being back on a movie set again. Mozilla is distributed geographically, but the hive is always buzzing on IRC and the countless websites that serve as the virtual headquarters for the team. It seems chaotic at first, and it may seem like everyone has something better to do than help you out (just like on a movie set), but if you pay attention and show that you're dedicated to learning the ropes, you'll find there are plenty of folks ready to mentor you.

I've worked in the tech industry a long time, on small teams and large, but I've never seen an apprenticeship culture as strong as Mozilla's. Seems like usually the company you're working for figures that if you're smart enough to get hired, you're smart enough to just shut up and do your work. They give lip service to "career growth" and send you off to special training programs, but it doesn't really have any sort of impact, because it doesn't hit you where you live and breathe. If you want your team to be constantly improving, then learning and teaching needs to be part of everyday work, not reserved for some quarterly seminar.

Labels: apprenticeship, mozilla