Thursday, June 07, 2018
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
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!
What do you think? I'm sure I've just scratched the surface… Hit me up with questions if you've got 'em!