At around age 5, I learnt to ride a bike. My dad had already taught my two older sisters to ride their bikes, and this time he decided there would be no training wheels involved. His reasoning: if I learned to ride with training wheels on, I’d have to start from scratch once they came off. Learning to ride with training wheels on didn’t actually teach me how to ride a bike.
It turns out my dad was on to something — these days many kids start out with a balance bike (and kids riiiiip on these bikes). When these kids come to ride a “big kid bike”, it turns out that they have already mastered the most important skill in riding: balance. Adding in pedals becomes an upgrade, giving kids more freedom and the ability to go faster. They don’t feel like they’re starting from scratch.
OK, but Claire, don’t you normally write about tech? What’s going on here? (Yes, but also, I like bikes!)
I think this idea of training wheels vs. balance bikes feels relevant wherever there’s a steep learning curve. In tech, there’s a lot of these steep learning curves. Let’s say a new coworker joins my data team: someone who knows how to write SQL in a web IDE, but our team requires her to check her queries into our git repo. There’s a lot of ground between writing in a web IDE and being proficient at version control.
At the moment, there’s sort of two ways to get my coworker comfortable using git:
- The deep end: Get her comfortable using the command line, a code editor, cloning locally, running git commands, etc.
- The training wheels: Use a GUI / our git provider’s inbuilt edit functionality to perform git actions.
I don’t love either of these approaches — the deep end means that it might take a few days of teaching to get my coworker comfortable with adding queries to the repo, while the training wheels of a GUI means that she won’t actually learn how to use git, especially for more advanced workflows — take away the GUI and we’re back to square one.
So what’s the solution? Finding the balance bike: the approach that will isolate the core skill of checking a file into version control, while simplifying other complexity. For this specific example, it might look like:
- Setting up my coworker’s computer for her, so she can get straight to the good stuff, without worrying about things like
$PATHvariables. (Pro tips: Document exactly what you did to set up their computer, so your employee can come back and read it later, once they’ve mastered version control. Also have them join when you set up the next hire’s computer so they get the chance to apply their new knowledge to this process.) - Taking the time to create a sandpit repo for my coworker to practice in, before getting her to work on our main repo, which is far more complex.
- Recommending tools that simplify a process, without abstracting the core operations away. Think VSCode over Vim.
Whether you’re onboarding a new coworker, writing a training course, or building software, ask yourself: “Am I giving someone training wheels, or am I giving them a balance bike?”
Related content:
- CLUI: Building a Graphical Command Line: This post from Replit looks at what it means to provide a balance bike within a piece of software. I found myself nodding my head a lot as I read it.
- Fig: Really diggin’ this beta software as a balance bike
- Progressive disclosure: I learnt this term from my good friend Joel and have continued to use it since!
Thanks to Grant Winship for helping me thought leadership this one! (That’s a verb, right?)
