The MX apprenticeship has been a lot of work and fun so far. This blog post is the beginning of an effort to document what I’ve learned along the way.

The Goal

I initially got interested in the idea of an apprenticeship while listening to the ruby rogues episode with Joe Mastey and Jill Lynch. I help organize a local ruby meetup group, so I liked the idea of helping new engineers. I also love my job at MX and want to see the team grow.

My early motivation was focused on facilitating the learning that comes with a first professional programming job, but I knew that goal of the apprenticeship needed to be focused on the company sponsoring it. I decided that the primary objective was to add amazing engineers to the MX team.

Amazing People

Based on my experience in the local Ruby community, I believed there were some really amazing programmers who were self-taught that were struggling to find a first job programming. I also met many bootcamp graduates with the same problem.

The shortage of senior engineers has made it really difficult to get a job as a junior developer. Many companies think they can’t hire junior engineers because they don’t have enough senior people to train them. There are also serious bias issues throughout the software industry and especially in the hiring processes.

I had no solid evidence at this point, but it seemed there was a large pool of extremely talented and hard-working people that was underutilized.

The Gap

On our team, we usually only considered hiring someone if they had programmed professionally for at least a year. This is partially because our team has no managers and no task assignment. This autonomy is great for engineers with a lot of experience, but makes it very easy to get lost as a new junior developer. If we wanted to make an apprenticeship work for us, we needed the apprentices to have skills and experience similar to someone with one full year of professional experience.

Does it actually take a year to gain that experience?

My first job wasted a lot of time because the experienced people on the team were too busy to provide guidance. I often spent countless hours trying to track down a single bug. I remember losing sleep over a database query that took too long no matter what index I tried to create. Later another programmer explained how indices are handled in the database and it was immediately obvious why my we needed to change the schema rather than add an index. I rarely got feedback on my projects unless they broke something in production. How much faster could I have gained “1 year of experience” if I had spent just an hour or two on those issues? What learning experiences would I have missed out on?

I also had a few experiences at my second job where the company was short handed and they gave projects to me and another new engineer. Neither of us was qualified to tackle these projects, but we both learned an immense amount because we felt responsible for the outcome and we learned constantly from one another. There was no friction about who was working faster, or who had more experience. We just worked really hard to make the project work and learned a lot along the way.

Talking to other engineers, I found that my experience was not unique. Learning to program is often fraught with huge wastes of time and only occasionally do you find yourself in a context where the learning comes quickly. I had no good way to calculate how inefficient this process might be, so I made a guess that we could fill this gap with a three month apprenticeship.

What Makes a Good Apprentice?

We had a lot of discussions internally about who we wanted to bring in as apprentices. Would we consider hiring people with no programming experience at all? Did long-term potential mean more than their current skill set? What evidence of long-term potential were we looking for?

My biggest fear was that we might hire people as apprentices, spend 3 months and find that they had not closed the gap in skills and experience. This is my definition of failure.

To mitigate this risk we decided to aim our apprenticeship at people with enough programming experience that they could already build some sort of web-based CRUD app. We preferred experience in Ruby because that would be the tool they would be using in the apprenticeship. We felt that this skill requirement was higher than we wanted, but we didn’t have enough evidence yet to try filling a bigger gap in skills.

We decided that once someone had met that minimum bar we wanted to heavily weight our decision towards long-term potential. The evidence we would look for was a track record of being self-motivated to learn new things and tackle hard problems.

This was still a somewhat ambiguous criteria, but we were comfortable with the ambiguity because we knew that we were going outside the normal hiring practices.

What Makes A Good Apprenticeship?

I liked the idea of a set curriculum for a few reasons, but my attempts to write a curriculum ended in dismal failure. Being a developer != being an educator.

Around this time I stopped thinking of how to teach more efficiently and started to think, “how can the apprentices learn four times more efficiently than I did?” This change in focus felt right. It wasn’t our job to fill the gap. We needed to create a context where the apprentices could be in that sweet spot of learning. I decided that being part of a team of peers and having access to more experienced developers were the two key things we would focus on.

The peer aspect would be handled by hiring apprentices in a group. They would be assigned projects as a team to encourage collaboration.

For mentorship we decided to have a direct mentor and a rotating schedule of senior mentors. This direct mentor has between 1 and 3 years of professional experience and sets aside one hour each day to helping their apprentice. Senior mentors have 5+ years of experience and are on a rotating schedule to help provide a broader range of experiences. Each week there is a single senior mentor who makes 90 minutes available to each apprentice. Apprentices mostly dictate the way mentorship time is to be used. Mentors make the resource available, apprentices choose how to use that resource to make their learning time efficient.

The Plan

At this point we had a few ideas about who we wanted to find and how we wanted to help them learn. None of these ideas were founded on research or expertise. What could go wrong? In typical developer fashion, we assumed we could significantly change outcomes by applying just a few simple rules to a complex system.

Despite the lack of credentials for these ideas, I continued to feel convinced that participating in this type of apprenticeship would have made my early development life a lot better. Surprisingly, my company went along with the idea and we started planning for an apprenticeship that would run from September to December 2015.