When my 6-year old daughter was three, she was at Kettler (where the Washington Capitals practice) and saw them practicing. She turned to my wife and said, “Mommy, are those Hockey boooooyyyyyyyssssss?” My wife said, “No, they’re Hockey Men.“
She was smitten, not with the Hockey boys, but with Hockey (I refuse to admit she was smitten with the Hockey boys). We started her on Hockey Skate lessons at Kettler the following year, when she brought it up again.
If you’ve ever watched hockey players skate, there’s a lot going on there. The class taught her to fall properly, to cross her feet the right way, to get up from ice quickly, to stop, to go, and to generally get used to hockey skates.
She hated it, she felt like it went too slow.
So she stopped wanting to go.
We shifted strategies, and next season took her to a local Ice rink that taught a “Snipes and tykes” program, which was a different way of learning: They would teach the basics of Hockey and skating, but in a play based atmosphere, with less time spent on the mechanics themselves than on those mechanics + real world fun situations for 4-8 year olds.
She liked this approach better, and suddenly wanted to do more hockey lessons. but, and this is crucial, she’s probably missing some of the mechanics that would make her successful in actually skating and playing hockey.
That’s ok, because she’s six, and she’s got time to learn.
As programmers, school tried to teach us the former approach; and bootcamps and our professional work emphasizes the latter, and we start to eschew those basics, those mechanics that we actually need but are boring. Somehow, TDD got swept up in all of that, and became one of those boring things, a lot like learning how to fall while hockey skating. It’s important, and it’ll help you when you least expect it, but do you really want to spend time practicing it?
Learning TDD is a bit like going back to the basics; but if you’ve spent time programming, you’ll be able to see how modifying those basics just a bit and combining those practices with necessary mechanics makes it easier to produce better software, faster.
It feels boring, which is why it’s been ignored for so long, but it’s useful and when you dive into it in the context of a real-world project, some of the mechanics come alive, and that’s where TDD gets fun.
Not as fun as watching the Capitals practice, but close.
If you’re interested in diving deeper into how TDD can help you deliver software faster, with fewer bugs and a more stable delivery cadence, sign up for my forthcoming course on TDD using .NET. By signing up you’ll get periodic emails and updates about the course, as well as a subscriber’s only discount that’s… well… only available to subscribers.