I recently listened to a great episode of the Talking Code podcast on how to go from a junior developer to a senior one. The talk was with Ben Orenstein of Thoughtbot, a company that knows a little bit about leveling up developers.
The episode peaked my interest since I‘m in the home stretch of my apprenticeship with LaunchPad Lab. During that time my focus has been almost exclusively on learning how to become a better and more effective developer. The episode also got me thinking about what I feel makes a good apprenticeship, because let’s be honest — it’s not glamorous to be an apprentice. In the wrong hands an apprenticeship can look like little more than cheap labor.
What happens in a good one is an entirely different experience. A good one creates an environment that’s challenging, but safe. It’s a place where as a new developer you can push your limits without the fear of screwing up. In my experience, and from what I’ve heard from other developers, an apprenticeship can make or break a budding developer. If this experience is so crucial, what applicable ideas or practices should every apprenticeship have? Here are a few I’ve settled on:
1. A DEDICATED MENTOR
I can’t speak for other dev shops, but in my experience this has been the most important aspect of my apprenticeship. Time and time again I find myself writing code that works, but that I can tell is… let’s call it sub-optimal. Something doesn’t feel right about it. It smells funny and it’s definitely not DRY.
When I used to work alone that kind of code was good enough, technical debt be damned. When I’m paired with a mentor questionable code is a great opportunity to sit down and refactor. Each time we pair I learn something new or apply a concept I’ve read about but never implemented. I can safely say I’ve isolated more dependencies over the past three months that in my entire developer career before that.
2. SUGGESTED (AND REQUIRED) READINGS
This is the academic portion of an apprenticeship and it shouldn’t be overlooked. Remember those concepts I said I’d read about, but never implemented? Most of those have come from reading books like Sandi Metz’s Practical Object Oriented Design in Ruby or Shyam Seshadri’s and Brad Green’s AngularJS: Up and Running. These books were given to me by fellow developers and have helped shift the way I approach writing code.
3. A TIMELINE WITH AN END GOAL
Having a timeline helps out both sides, the apprentice and the instructors, and having a clear end goal allows both sides to track the apprenticeship progress. It’s good to know what the explicit end goal is. Is it that the apprentice comes on as a full-time developer? Great, but what does that look like? Does it mean that you don’t need to pair anymore or does it mean you’re leading a project? Knowing what the end looks like will help inform every step along the way.
4. SIDE PROJECTS
The flip side of client work is that some decisions are made for me. Some decisions are smaller, like a minor design detail, but some are large, like choosing coding languages. Either way it’s a different experience from building a solo app.
Side projects have given me a chance to flex my entire product design skill set, from idea conception to deployment. During my apprenticeship I’ve built a Slack / MailChimp integration and am currently working with other team members on a photo book project. Having these projects as playgrounds to test out new concepts and processes has sped up my growth substantially and I can’t stress their importance in an apprenticeship.
5. HONEST AND OPEN COMMUNICATION
This one is pretty simple. And you know what? It should be easy. All it takes is for both sides to be okay with sounding stupid. The apprentice needs to be able to fail and ask questions that might sound dumb to a senior dev. The mentor needs to be okay with an apprentice saying, ‘hey this isn’t working’. Checking in regularly goes a long way towards keeping the dialog running and makes sure neither side feels unheard. This simple step makes both sides happier day to day, which undoubtedly makes the apprenticeship more fulfilling in the end.
These guidelines are not hard and fast rules, but they’re observations I’ve made over the past three months. My apprenticeship at LaunchPad Lab has been great, but I’ve heard stories of budding developers who haven’t been as lucky. None of these guidelines are difficult to implement, so to all the dev shops cranking out unhappy devs: what gives?