Article summary
Today, I’d like to share a story about how one of my wizard mentors taught me a new skill (test-driven development) and really got it into my brain. Not by lecturing me or forcing me to do it, but by patiently, persistently encouraging me to grow.
This post is part of a series on how to train up your fellow software wizards. You might also like:
- Mentored by Wizards, Part 1 – “You’re Worthwhile”
- On Becoming a Wizard: Strategies for Keeping Up as a New Developer
- Wizard Developer Skills: Conjuring Joy From Pain
- Wizard Consultant Skills – Protection Spells for Saying “No”
- Julia Evans’ zine that inspired the series
Learning new things is hard.
The premise of test-driven development (TDD) is simple: Before you write code, write tests that will validate that your code is correct. But TDD has a set of characteristics that make it simultaneously super-hard and super-important for new developers to learn:
- It can be a little tedious when you first start out, which makes it easy to put off.
- It’s hard to see why it matters without having been burned before.
- It’s very easy to do dogmatically, which encourages new students to challenge it.
- It’s supposed to protect you from your mistakes, which means you have to admit that you make mistakes.
- If the people around you are doing it well, you’ll rarely notice how powerful it is.
I list these particular traps because I managed to fall into every single one of them at one point or another. Still, I stumbled my way through leading my first project without too many failures. Guiding me down that path was one particularly patient Atom whose qualities I’d like to share here.
“Maybe if you had written a test…”
This Atom was very patient with me while I learned the importance of TDD. Rather than being pushy or controlling, they allowed me some room to make my own mistakes (more on what “some” means below). Every time something went wrong, they calmly pointed out that perhaps a test would have caught the issue. I found this irritating, but I learned, over time, to protect myself from it.
At first, I tried defending my ideas. I was trying to increase efficiency; I wanted to (over-) use a new style of development that leveraged types as protection instead of tests. I wanted this person to get off my back by whatever means necessary, so I came up with every argument I could. Most of them failed; some of them gained me a little bit of traction.
Eventually, after a handful of snappy arguments, we found a sense of peace in our differing opinions. Still, every time I tripped, they’d ask me again: “Where was the test that should have caught this?”
The verbal arguments weren’t working anymore, so I ended up modifying my processes to provide better answers, in hopes that this person would stop quizzing me on TDD. Soon, I could say, “Here is the visual test.” Soon after that, I found myself answering, “Here is the test, and here’s why it failed.” Then, “Here is the test, and I have already fixed it.”
Allowing me to learn
Perhaps the moral of the story is obvious by now, but let’s examine further.
This mentor could have gotten annoyed with me; they could have tried to impose some TDD “rule” in an attempt to force me into compliance; they could have pushed too hard and sacrificed our relationship. But if they had, I wouldn’t have been willing to listen and learn from their arguments.
This person’s ability to guide me via their own learnings led me to adopt TDD fully; I understand and believe in its value well enough not to just apply it to my own codebase, but even to teach it to others in this same way.
Good mentors offer many layers of patient, persistent teaching and learning. As I reflect on and write about this story, I find new layers of value and nuance in each moment. More reflections on powerful mentorship/wizardry coming up soon!