What We’ve Learned From Gaslight Apprenticeship Program Iteration One
Almost 6 months ago we partnered with a client to launch an apprenticeship program. The finish line is in sight for the first set of apprentices, so it seemed like a great time to share what we’ve learned so far. We’ve learned a ton: more than will fit into a single post. I’d like to start by sharing a couple of the most important and valuable learnings.
Adding apprentices makes your whole team better
We started with a hypothesis: by matching a team of apprentices with an experienced developer mentor we could deliver valuable software at the same we were welcoming people into the field of software development. I served as the developer mentor and my initial role was to recruit and hire the apprentices. Once they were hired, I was to work as a developer on the team, coding alongside the apprentice while teaching, mentoring, and doing whatever was necessary to help them be successful.
Our thinking here was that by adding an experienced developer and mentor we could make sure that the team continued to deliver as the apprentices ramped up. We anticipated a drain on the productivity of experienced developers if they had to take significant portions of their time away from delivering features to teach apprentices. Part of my role was to try and prevent this.
What I’ve learned through the program is incredibly exciting: rather than a distraction, the apprentices make other developers better. You’ve probably heard the saying: the best way to learn is by teaching. We got to see this first hand on our team. I had anticipated most of the teaching and mentoring would come from me, but having the whole team doing this is way better. We had a team of a couple of experienced devs in addition to myself. They jumped into teaching quite naturally. I now believe this to be the rule rather than the exception: given a supportive, safe environment, humans just naturally dig helping other humans. It was also fascinating to see how our pace of delivery compared with other teams. We had a large project with many moving parts and our portion of the overall system was one of the first to be ready to go to production.
The other ways apprentices make a team better are a bit fuzzier, but perhaps even more important. Every experienced, skilled developer I’ve met has at some point (probably multiple points) had to deal with cynicism and burn-out. Being able to pass on what you’ve learned to an enthusiastic, bright new person is one of the best cures for this I’ve ever seen.
Most good developers became developers because at some point they were really excited about being able to get a computer to do something. If you’ve lost this excitement or even just seen it wane a little, try showing what you do to someone new. Seeing them get excited and seeing the light bulbs go off in their head is really rewarding. I advise any developer who’s been at it for awhile to try it.
Apprentices have made the team better in one more way: being an example for someone else really motivates you to set a good example. There are times where I might be tempted to skip writing a difficult test or leave some code around that I know is a little hacky. With an apprentice, you naturally want to show them the best way to do something. It turns out that makes you better, too.
Aptitude and enthusiasm over knowledge and skill
To put this in Agile Manifesto terms, while we value the items on the right, we value the the item on the left more. Are knowledge and skill important? Of course they are! This was obvious to me from the beginning, and the reason I have a coding challenge as part of the selection process for apprentices. However, what I knew intuitively I now know experentially: it matters far more how quickly you learn and apply knowledge than it does what you know on day 1. Our instinct is to hire for skills. I even now feel a strong compulsion to do this. Skills are easier to assess and test for. They are (somewhat) objective. Aptitude and enthusiasm seem more squishy and nebulous. But they are also the best predictors of success for an apprentice. To see why, please look at this graph of data that I made up:
Hopefully it conveys the obvious: the slope of the line is what matters. Given any reasonable amount of time (and a 6 month apprenticeship is plenty!) it matter less where you start than where you end up.
But what do we do about that? How do we assess aptitude and enthusiasm? Enthusiasm isn’t something you can test for, but in the words of the old supreme court justice, “You know it when you see it”. For us, one of the candidates just kept showing up. She was there every week at our Friday Gaslight coffee getting help on the coding challenge. By the time we were choosing who to hire, everyone in the office knew her name and was rooting for her. Even though she didn’t do as well on the coding challenge initially, we took a chance on her and hired her. It couldn’t have been a better decision.
Aptitude, on the other hand, is something you can test for, I just didn’t know how to do it when we started. As we went along and I got a chance to see the apprentices learn and grow, I started talking to people about what I saw. My friend Zak pointed me at an intensive developer program in San Antonio that had all their students take a math and logic test at the beginning of the program. They tracked their students performance during the program and found what seemed like a pretty strong correlation. I was super intrigued and reached out to them, and they were kind enough to spend an hour or two talking about it with me and shared the test with me. I’ve since added the test to my apprentice selection process as another useful data point I can use to gauge how easily someone is going to be able to take in and apply the immense amount of abstract concepts we throw at them during a 6 month period.
We could not have had a better partner to try out this experiment. If you look around their office, you generally see groups of developers talking to one another and working together. There is a strong culture within the organization of helping and learning, and this is true within teams and across teams.
Beyond culture, there are also some specific practices that help make a good environment for apprentices. I’d go so far as to suggest that they are critical: I wouldn’t attempt an apprenticeship at an organization until I had these practices in place. The good news is these line up well with Agile. Hopefully, if you have embraced Agile development you are aware and doing some of them already.
Test Driven Development
This practice is key to doing effective development in general, but even more important for beginning developers. According to the Dreyfus model of skill acquisition, one of the key things a beginner needs is simple rules to follow. TDD is a nice simple pattern to follow: red, green refactor. It generally leads to good code, especially under the guidance of a mentor to help you know when the simple rules are not enough.
This practice is essential. There’s a reason we add apprentices in pairs. Adding a single apprentice to a team of experienced developers just doesn’t work as well. By pair programming, and just as importantly, regularly rotating pairs, each apprentice gets the maximum benefit. They get exposed to multiple points of view and experience level, as well as getting regular chances to compare notes and encourage other apprentices. On our team, we randomly assigned pairs generally twice a week, never less than once a week. It takes some discipline but is well worth the effort. I can’t imagine trying to do apprenticeship on a team that doesn’t pair.
I’ve enjoyed the last almost six months tremendously. There’s nothing more invigorating that getting a chance to work with new, enthusiastic developers each day. I’m also convinced that it works, and it can make your team better. If you would like to be an apprentice, or bring apprenticeship to your company, let’s talk. Reach out to us at firstname.lastname@example.org.