Over the past year and a half, we’ve been building a developer apprenticeship programme. What started as a small experiment has since evolved into a successful programme for mentoring junior developers and facilitating a smooth transition onto our product teams. Now that the programme has been integrated into our engineering culture, I want to share how this programme came about.
Meet Bryan
Last year we met Bryan. He’d been in marketing for several years, working for a variety of non-profits. For a number of reasons, he wanted to make a career switch into tech, and enrolled in Bitmaker’s 9 week Full Stack Developer program. We’ve interviewed many graduates from code schools, but haven’t hired any because their limited experience isn’t sufficient to meet our technical expectations. Yet Bryan impressed us. Like many other code school grads, he had developed and launched his own website, but what stood out to us was the care he invested in the details. And although he was only starting out in web development, he’d published a handful of blog posts about what he’d been learning.
So here’s someone who’s attentive to details, enthusiastic about learning, shares what he’s learned, and focused on shipping. We know that takes commitment and courage, especially for a new developer, and we value that, so we wanted to get to know him better.
We invited Bryan to go through our standard interview process which includes a coding exercise followed by an on-site technical interview. It was evident that the questions we asked and the exercises we presented him with put him outside his comfort zone, but he responded by asking insightful questions, clarifying the problem, and eventually working his way to the solution.
Over the past year, we’ve met many such candidates. Individuals with diverse backgrounds, who have a growth mindset, who are willing to ask for help, and who can think on their feet. These are the the kinds of attitudes and characteristics that we look for in our developers. Unfortunately, we turned most of those candidates away because their technical skills weren’t strong enough. With Bryan, we were ready to try something different.
We knew that Bryan couldn’t hit the ground running with our codebase. But given his character and approach to learning, we wanted to find out how long, when offered the right kind of mentoring, it would take to become an effective contributor on our engineering team. With his full agreement and enthusiasm, we kicked off our first apprenticeship program.
What did we set out to do?
Our goal wasn’t to turn Bryan into a rockstar programmer in three months. That’s not possible, nor even desirable. Rather, we wanted to facilitate Bryan’s growth such that he can pair collaboratively on feature stories in our production codebase. Of course, we intended to invest time in strengthening his programming fundamentals, but we also wanted to focus our efforts on building the professional practices of developing high quality software. What we were looking for in Bryan was a commitment to learn and put what he was learning into practice. For our part, we committed to providing consistent one-on-one mentoring. We know that maturing into a professional developer takes years, not months, so we didn’t set unreasonably high expectations for his technical expertise. Our goal was instead to support Bryan in gaining autonomy such that he could self-direct his technical growth. This, we believed, would serve as the best foundation for advancing in his career as a professional software developer.
Agility or Curricula?
Our initial instinct for the programme was to structure it as a bootcamp — which, for us, meant having a fixed curriculum and clear expectations for what the apprentice needed to learn. But we soon abandoned that approach. One reason was because there simply is too much to learn to become a great developer, and we couldn’t reduce this to a fixed curriculum. Also, this approach was inconsistent with the agile methods that structure the way we work. Instead of investing heavily in upfront curriculum planning, we adopted an inspect-and-adapt approach to tailor the learning objectives to the needs of the apprentice.
Although we were intentional about iteratively inspecting and adapting to guide the programme, we adopted a lightweight structure that organized the apprenticeship into three phases, each of which focused on a theme:
1. Fundamentals
2. Apprenticeship project
3. Immersion into production code
Fundamentals
During the first phase, we focussed on the fundamental technical Extreme Programming practices: pairing, TDD, small design and refactoring. We carried this out by doing a lot of pairing on Ruby katas with a mentor to develop competence using basic TDD.
Apprenticeship Project
After a few weeks of fundamentals, Bryan kicked off an apprenticeship project, which was to serve as a sandbox for applying what he’d been learning to a web app that used our tech stack (e.g. Rails, RSpec, Postgres, Angular). This project gave Bryan the opportunity to code, code, code, and to learn by doing. He developed his app using a wide range of TDD strategies, and also encountered many problems that he’d find in our production code, for example, resolving n+1 queries. These were important learnings, and they were easier to acquire in a smaller codebase than to attempt to understand them within the complexities of our production code.
Immersion into Production Code
Once Bryan had made a significant dent in his apprenticeship project and increased his confidence with TDD in a Rails app, we began immersion into production code. This began by simply reading code and diagramming logic and data flows. Once he was familiar with our application’s structure, we started with simple defects, and soon progressed to increasingly larger feature stories. Naturally, we used pair programming, which is our default manner of developing code at Nulogy.
Was it Worth It?
This was a significant investment on our part. Not only were we paying Bryan to focus on learning rather than contributing, we were also pulling productive developers away from development work to mentor him. But it was likewise a significant investment on Bryan’s part. Yes, he was being paid to learn — opportunities like that don’t come around often — but he was also asked to expose his gaps, confront them, and then put in the many hours, both during regular working hours and also during evenings and weekends, to close them. This required humility, courage and discipline.
The outcome, however, was an outright success. Bryan not only deepened his technical skills, he also strengthened his capacity for learning, and he’s continued to advance his expertise since coming onboard as a full-time developer. He still has a long road ahead before he grows into a journeyman developer, but he’s demonstrated the attitudes and discipline to grow into that role over the coming years. And his enthusiasm for learning not only supports this professional growth, but also energizes the learning culture on our engineering team.
Bryan’s apprenticeship began as an experiment, and although there were some bumps along the way, the apprenticeship program remains an important part of how we’re growing our engineering team and culture.
To learn more, check out Bryan’s post:
This article was written by Nulogite Cameron Woloshyn.
Enjoyed this read? Click the♡ ! Want to learn more about what its like to be a Nulogite? Follow us.
