Jan 29, 2019

Apprentice Developer Best Practices

Let’s face it there simply isn’t enough good developer talent. It’s been an issue for years and it’s going to remain an issue probably at least until the next recession if not longer. We’ve always had great success in creating a team or two who can knock anything out of the park. But scaling is a constant struggle. To handle the sales pipeline we need many delivery teams that can perform at the same high level of productivity. One of our approaches has been to grow our own.Over the years we’ve had great success growing our own developers. Every semester we have about a half dozen interns from local universities and even high schools. It’s common for the interns to return again and again each year as they progress through college. We spend a lot of time making sure they can do the work, that they’re a good cultural fit, and that they can they interact with other members of the teams. It’s not unheard of here at RIIS for someone to start as a senior in high school and then become a full time employee when they graduate from college. We get the interns via word or mouth and I also teach programming at a couple of universities to help identify potential candidates.But we still struggle to help our developers blossom in those difficult early years as they move from new graduates to fully functioning members of the team. And unfortunately the odd graduate has just not worked out. So we’ve spent a lot of time working on apprentice programs to see how we can coach these young developers into better developers, or craftsman.

Lesson learned #1 – Apprentices should work on real world projects sooner rather than later, they don’t have to be billable but they need real customers

At it’s most basic an Apprentice Program aims to get the junior developer up to a senior level agile developer or Craftsman. Every company may have their own definition of what that means but it typically includes some of the following:-

Test Driven Development
Refactoring
Unit Testing
Agile processes
SOLID design principles
Pair Programming
Continuous Integration

An Apprenticeship is also not just about coding. At the core of any Agile apprentice program should be Five Agile Values, namely Communication; Simplicity; Feedback; Courage; and Respect. Some practitioners also say trust and transparency should be added to the list.

Not surprisingly an Agile software developer apprentice is similar to those of a traditional craftsman’s apprenticeship. For example, it recognizes that learning requires practice. There is also an insistence of pride in one’s work (i.e. perfecting one’s craft) and taking direct responsibility for it. For a craftsman, reputation is everything – and so it should be too with the software developer, both during and well beyond their Agile apprenticeship.

Lesson learned #2 – Structure is important, apprentice teams find it difficult to self organize

Peter McBreen’s book on Software Craftsman came out in 2001, so the concept of going from Apprentice to Journeyman to Craftsman has been around a while. There is lots of content out there to borrow from Universities, companies and developers. Here’s a small sample.

There are also many online learning resources that cover many of the topics. Pluralsight, LinkedIn, Industrial Logic and Clean Coders videos.

Apprenticeship programs live or die depending on the quality of their interactions with their mentors. The mentor coaches the apprentice and shows them how to write quality code. None of the key skills that we’re trying to transfer from the mentor to the apprentice are easy. If the apprentice feels that they’re bothering the mentor then they are much less likely to have a quality apprenticeship. Sometimes the mentor hasn’t mastered their own craft and the apprentice will get frustrated. If the mentor feels that they don’t have time to coach the developer then the apprenticeship will fail.

Good quality oversight is needed to make sure everyone is getting what they need and that there aren’t unreasonable pressures being put on the mentor to do their day to day work as well as coach the apprentice. Pairing on real projects is often the best solution.

Lesson learned #3 – Make sure mentors are allocated time to pair and are not being borrowed from other projects when they can spare a moment

The first iteration of our Apprentice Program seemed to go on for ever. Developers couldn’t define what an Apprentice, Journeyman or Craftsman meant. And more importantly they didn’t know when the went from one level to the next. This caused confusion and it seemed that becoming a Journeyman or Apprentice was too subjective and ultimately developers left to go elsewhere for more money.

The second iteration of our program fixed that problem, but the work was less flexible. Apprentices primarily worked on bench projects and didn’t work on any billable projects. Sure it’s really easy to control when and where you learn TDD and how to set up a CI server if you’re working on yet another Roshambo app but you need to be on real world projects to really learn your craft. And because the projects aren’t billable there’s less chance that you’ll be able to pair with a Craftsman.

In the end we have a defined timeline for moving from one stage to another based on how many customer projects the developer has worked on with his or her mentor.