intermediate_ruby     about     articles

Building an Apprenticeship Program

Background #

I’m working on building an apprenticeship program. It’s something I’ve been working towards, and have wanted to work on, for years. I think it’s going swimmingly.

Someone DMed me on twitter and asked:

Do you have a page for the work you are doing with apprenticeships?

The person leading our internship program (open to career changers) just left and we could use some expertise.

I’m at [other company] now.

My actual answer to this question didn’t fit in a twitter DM, so here we are…

Oh, and there’s a “right time” to write things (source). this is the right time to capture the sketch of these thoughts, relative to the work I’ve done over the last few weeks and months.

why should [your company] care about an apprenticeship program? #

I’ve thought a lot about why do companies not seem very invested in training up engineers. First, lets admit we’re not approaching this from a neutral or sustainable point.

It’s hard to hire these days. Everyone is concerned about hiring. Recruiters make $30k for placing a mid-level candidate at a company, and that is actually money very well spent. Once you’ve got some experience under your belt, it’s a very good job market. There are companies cranking out engineers who have displayed extreme tenacity and effort over months, but they’re not training them very well.

You and your team will feel healthy and productive when you have a reliable mechanism by which your team can take “junior” engineers, and, once you’ve got a system in place, you can get them ready to do useful, production-ready work on your application.

Figuring this out is a great retention tactic for engineers on the team, and it’s a great way to build meaningful trust with potential hires. If you train them well, treat them fairly, pay them fairly, and figure out how to let everyone enjoy themselves the whole time, you’ve got the foundations of a strong team that sticks together. More on that in:

The cost of a bad hire is very, very high. Conservatively, $150k and nine months of team-wide opportunity cost, for a bad W2 hire1.

With a bit of a structured program in place, you’ll do a few things, simultaneously:

  • Forever reduce company exposure to the risk of a “bad hire”
  • shorten the time-to-first-value for all future engineer hires (not just Early Career Software Developers)
  • improve team retention/psychological health of existing team

Here’s my “desired outcomes” for three different groups: (executive/cto/vp engineering, senior developer/developer manager, early-career software developer)

https://josh.works/railsconf-cfp-draft-outline#desired-outcomes

story of this internship program #

I’m working with https://www.startup.dev/, building out apprenticeship program. I connected w/John Mosesman after this rant:

We chatted, found a lot of philosophical and practical overlap and alignment, and now myself and the two engineers I mentioned are up and running at startup.dev!

Here’s a quick sketch of my observations/thoughts

3 leading indicators of success from company’s POV (I.E. company pre-reqs) #

Not all companies can or should launch an internship program. A poorly-handled, poorly-planned program that doesn’t avoid obvious pitfalls shouldn’t be done. You will waste time, money, and career capitol. Here’s three “go/no-go” indicators:

1. the company feels comfortable leveling up engineers “one-off” #

Working with early-career engineers to become mid-level engineers takes work and skill. You/your team should be confident that they can level up the skills of anyone who joins, even if they don’t always feel like they have time.

If you have at least one or two engineers that say things like:

I love to help less-experienced people on the team become more skilled

you might be in a good spot.

2. the company is comfortable with the right timeline #

It’ll take at least two months to execute this program and get skilled engineers out of it. The biggest time component is how quickly your company can move, and as we know about timeline estimates of unfamiliar things in software - when it’s the first time your company has tried to execute this task in this way, uncertainty abounds.

If anyone in the management chain is likely to throw a fit if they see someone on the dev team that isn’t

slinging a lot of code

this is going to lead to a lot of uncomfortable psychological pressure on all involved parties.

3. Key individuals can articulate many explicit and implicit benefits of solving this problem well #

Like anything new, when there’s not a lot of good paths from here to there, you’ll want to have strong buy-in at all levels. A sign of this is when each different involved person can extemporaneously attest the value to all parties of something like this, especially when those people represent several contiguous nodes of authority levels within an organization:

  • line engineer
  • engineering manager/dev lead
  • CTO/CEO

This makes it easy to quickly get the right actions taken at the right level. Imagine a line engineer trying to compensate for a CTO that doesn’t care about training the next generation of employees. Sisyphus, rock.

3 inputs available to leaders of the program #

So, all the go/no-go indicators come up “go”, and you’re ready to get started! Awesome. Here’s three things that you, the champion of the apprenticeship program can do to help ensure it goes well for all parties:

1. create sense of rest and peace and openness with the participants. #

It’s about a good system, not “outstanding individual behavior”. psychological safety will influence the long-term “slope” of growth. (source). This is fuzzy, but important. If you’re here and trying to sort it out, ping me and we’ll talk through it.

2. emphasize that “success comes from a good system and process, not individual heroic effort and/or long hours.” #

Because this is about the participants as much as it is the system, you can have the apprentices work on the program. The two apprenticeships I’m working with have, upon my instigation, created at least 20 stand-alone written pieces (some public, on Medium, some internal pieces of documentation) that are woven into existing documentation/”paths” that future developers will work through.

These pieces emphasize the role of systems, and reflection and going slow. (See A Mind For Numbers) for a deep dive on why success comes from a competent, effective system, not heroic effort and hard work.

3. pair, leave comments on PRs, commit trace, etc #

Do the work of actual software development. The goal isn’t going to be to just move a bunch of tickets across the board, but to create resources that other engineers will be able to learn from, about the ways you solved the problems, built features, etc.

Since i’m starting on the codebase at the exact same time as the apprentices, I’m in an extremely beneficial position of having software development patterns in my head, but no knowledge of this particular app. So, when I’m fixing things, or building things, I can just explain my process for making all the decisions that I make, and the ECSDs can then duplicate my work, in the exact same way, and learn some very useful tools along the way. And it only takes them maybe two hours to work through this thing I’ve made.

I pair, i leave comments on PRs, and more. I wish I paired more. Time has been very limited of late, and I’m making this up as I go as much as anyone else.

3 specific tactics for guiding growth #

The goal is to make a process and a system that encourages the tweaking/gardening of “itself”, with all participants having full creative control/input into the process.

This isn’t top-down “school”, it’s something very different.

1. commit tracing #

We’re onto ~week 3 of the program (I define the weeks as consistent effort on the same application). If you’re a “product shop”, this might be easier, as everyone works more-or-less on the same product.

Startup.dev is a consultancy, and we’ve bounced the apprenticeship program around a bit between projects, as we’ve tried to find the right fit accross a few dimensions. That means some early churn cost a little time/effort.

I’ve been kicking the tires on adding commit-tracing documents, outlining PRs made by the senior developers, to show how to take a PR from end-to-end. We start with the trello card or bug report, move through exploring the problem space to identify the fix, and then make the fix.

2. coach participants to write #

but don’t force it or rush it.

but don’t wait too long, either. strike while the iron is hot, etc.

Writing is good for the brain. I use as a leading indicator of growth a metric like “do the participants write publicly, every day, or nearly every day”.

I expect the participants in the apprenticeship program to quickly grow independent, and be able to solve novel business problems in reasonable ways, using the expertise available to themselves and their community. Writing is the Human API, so if you think clean code in Ruby is important, how much more important is “clean code” when writing for humans? (I’m not good at this. I can be verbose and meandering in how I write, but… i’ll refactor it all later)

3. aim for one merged PR/day as quickly as possible (2 weeks?) #

Ryan at Startup.dev suggested this, and I love it. As early as possible, all participants should be aiming for one merged PR per day. It could be adding/refactoring tests, or minor code refactors (once there’s tests for that chunk of code), and more. I’m working on a “library” of all our daily PRs, and how to extract principles to apply to your own apprenticeship program.

3 inputs available to participants of the program #

So, you just started as an apprentice somewhere? Congrats! Here’s how to be successful:

1. brag documents, gists/today-i-learned’s (process over everything doc), public writing #

WRITE IT DOWN! Write it all down. Every PR should have at least one adjacent piece of collateral. Start your own today-i-learned repo. Here’s mine, here’s the amazing TIL repo by Josh Branchaud.

If you ever think:

I wonder what Josh would recommend I do here…

I’d probably say “write about it SOMEWHERE.”

Please do so.

2. a daily merged PR #

This will feel like the hardest place to start, but it’s an exercise in decomposing problems into their sub-pieces.

  • bump the minor version of a gem in the gemfile (read the related CHANGELOG for that package)
  • refactor code (lol. easier said than done, but we’ll talk about this more soon)
  • not enough tests to feel good refactoring? add some tests
  • missing system tests for key app flows? Add your own. Add some even if it feels like test coverage is fine.
  • improve naming conventions (in the code or the tests)
  • start tiny feature work behind feature flags
  • contribute to the “supporting curriculum”

3 reasons I don’t really like the division of “leaders” and “participants” or “mentors” and “mentees” #

1. everyone contributes, just differently #

We’ve got some wicked smart apprenticeship participants. They’re practical experts in other domains, so I very much want to emphasize to them, at every turn, they are full participants in this process, they’re not “passive learners”. Unfortunately, the entire modern educational system drags people in the wrong direction on “how to learn well”. I see learning as deeply participatory from all directions.

2. strong trust required in all directions #

We need strong trust for anything like this to work. language matters. If we build a successful internship program, the achieved outcome isn’t “just”:

the current ECSDs become skilled developers

but it is:

the current ECSDs become skilled developers, and we have a process that we can move new developers through, and they will achieve success in less time and with less effort than anyone before them.

3. current “participants” should quickly become “leaders” of others. Don’t de-dignify with emphasis on their “inferior status”… and yet, there are leaders and current followers #

I expect cohort 1 to have a better experience than cohort 0, and cohort 2 to have a better experience than cohort 1.

The only way this happens is if the current participants know that one of the best things they can do is attend closely to their own experiences and when they feel frustrated, uncertain, discouraged, etc, and at minimum give voice to that, and eventually, figure out the root of it, and we’ll ameliorate as best we can that particular negative experience by tweaking the curriculum/process.

I want to be able to walk away from the apprenticeship program for a few months, at some point, and come back and joyfully meet the most recent batch of participants, and hear them talk about how much they’ve learned, the problems they’ve solved, and how amazing they correctly feel at the art/craft/trade of software development.

3 things I am working on right now to improve the next iteration of the program #

participants writing their own commit trace documents #

So, I’ve written now 8-12 commit trace documents, depending on how you count. It’s difficult, but deeply valuable.

detailed “code-a-long’s” #

So much more to say here. Here’s a list of all the code-a-long’s I’ve made, that are public, and you could start right now:

https://github.com/josh-works/ruby-exercises/#regular-projects

commit trace chunkier features #

I’ve so far only done small commit traces. I’ve got a much larger PR to do soon, I’m eager to see how commit tracing such a big diff feels.

Conclusion #

I’m very much at the beginning of all this. Just writing this document has been helpful, helping me clarify inputs and outputs and such.

Your company should do an apprenticeship program.

Want to talk more? hit me up. Email me, @me on Twitter, book a coffee, etc.

I’m happy to share my findings in ways that will help others run their own apprenticeship programs, or help them get strong executive buy-in and support for a program like this. Depending on what that engagement/time-frame looks like, we can definitely set up a retainer.

I’ve been doing a lot of cycles on free, public, high-quality learning resources focused on Ruby/Rails, and I’ll be working on publishing more and more about this apprenticeship program. Create a bit of a mastermind program on it.

Bibliography for this apprenticeship program #

I professionally mix data/ideas from different sources2. For examples of what this sounds like in practice, in fluid conversations, and what it might sound like for you and I to discuss this:

bloom’s 2-sigma problem #

By mixing mastery-based learning and 1:1 tutoring, “average” students become “98th percentile” students. (2 sigma = “2 standard deviations”)

This paper, and the specific methodological interventions, have fascinating implications for apprenticeship programs. Ask me about it some time.

https://josh.works/2-sigma-problem

pdf presentation of findings for above paper #

These are just slides for a presentation I gave in mid-2020.

https://docs.google.com/presentation/d/1sN_NqYbIlrnhNJOi9tIqn0kUCFqQrl23eUEwnPuenU0/edit?usp=sharing

railsconf talk: “Junior” Developers Are The Solution To Many Of Your Problems #

I gave a talk at RailsConf21:

https://josh.works/railsconf

The prep for the talk was fun.

railsconf prep notes #

Basically, my pitch to key decision-makers of this apprenticeship program.

If you’re strongly interested in an apprenticeship program, read the above notes.

The RailsConf walk was, to put it gently, a trashfire, and manifestly unfun. Never again. All my fault, but not fun at all.

https://josh.works/boulder_ruby_group

White Paper 1: Debugging Hiring: What Went Right and What Went Wrong in the Technical Interview Process #

Debugging Hiring: What Went Right and What Went Wrong in the Technical Interview Process

White Paper 2: Does Stress Impact Technical Interview Performance? #

Does Stress Impact Technical Interview Performance? (link coming soon)

White Paper 3: Hiring is Broken: What Do Developers Say About Technical Interviews #

Hiring is Broken: What Do Developers Say About Technical Interviews (pdf coming soon)

mind for numbers (book) #

A Mind for Numbers: How to Excel at Math and Science (Even If You Flunked Algebra)

secrets of our success (book) #

psychological safety paper #

William Khan: Psychological Conditions of Personal Engagement and Disengagement at Work

how complex systems fail #

How Complex Systems Fail

tacit knowledge #

Why Tacit Knowledge is More Important Than Deliberate Practice

The Phoenix Project #

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

A little Slope makes up for a lot of y-intercept #

https://josh.works/a-little-bit-of-slope-makes-up-for-a-lot-of-y-intercept

  1. Here’s how I did the math: https://josh.works/how-to-write-a-letter-of-recommendation-for-yourself#how-much-does-a-bad-hire-cost. A friend/VP of Engineering said my dollar figure is hilariously low. I agree with him. 

  2. For why this is good: https://josh.works/structural-holes-and-good-ideas 

💬 Comments

Post comment
Loading...