Small Goals: How Roller Derby Made Me a Better Programmer
A year ago I tried out for my local roller derby league, the Long Island Roller Rebels. Around the same time, I began to seriously study programming.
One Step At A Time
As I quickly discovered, roller derby has a steep learning curve. In its modern form it’s a young sport, so most players have not been playing derby since they were children. Most of us only skated a little at local rinks when we were young, clinging to walls and crashing into other kids.
Luckily, most roller derby leagues are prepared to teach new members how to skate from the ground up. Before you can play roller derby proper, you have to learn how to balance. How to pick up your feet. How to fall without hurting yourself. How to stop, in several different ways. How to go fast. Only after mastering the basics do you learn blocking, hits, jamming, game strategy, formations.
Learning to code was a similar progression. You have to understand arrays and hashes, conditionals and looping, before you can program anything more complicated. Command line interfaces and frameworks and AJAX come later. First, you have to master the basics – and those basic concepts are integral to your later success. You can’t build a Rails CMS without a fundamental understanding of variables. You can’t hip-check a jammer without knowing how to control your skates.
My slow, but necessarily incremental, progress in learning to skate encouraged me to patiently accept the seemingly endless – but also necessarily incremental – steps in learning to code. If I could master backwards transitions after a few weeks of trying, I could certainly master Ruby objects.
In roller derby, when you don’t quite succeed at a skill, it’s easy to see the consequences. You fall down. The jammer evades your block. You don’t quite do 27 laps around the track in five minutes. You fall down (again). It’s easy to see each failure as discouraging, but that’s no way to improve. It’s not a failure – it’s a learning opportunity. You pick yourself and try again, a little differently, a little better.
When coding, I treat each error the same way. Programming languages are delightfully logical: a bug or a failing test only happens because the code you wrote is followed to its logical conclusion. Each error is an opportunity to dive deeper into the language and learn how it works.
When I scrimmaged – essentially practice roller derby gameplay – for the first time, I was overwhelmed. Suddenly I needed to remember everything I’d been taught, but all at the same time. Defense, offense, blocking, strategy, staying upright, listening to my teammates. My focus was scattered. How was I supposed to get better at everything simultaneously?
The obvious answer: I wasn’t. If you tackle everything all at once, you won’t improve. I learned to set small, specific goals before every scrimmage, and worked on improving just one skill at a time. This week I’d stay in a wall with my teammates. Next week I’d watch the opposing jammer and communicate her position. Then I’d work on stronger plow stops.
Breaking down large coding projects in a similar fashion turned out to be key. A fully-featured functional web app can be intimidating. If I tried to tackle it all at once, I’d quickly become overwhelmed. Conceptualize each feature separately, and then start from the logical beginning – the first thing the user does. Step by step, by drilling down into each component piece of code, soon enough all I had to do was iterate over an array.
Just like how moving forward on skates is fundamental to the sport of roller derby, that kind of basic code is crucial to the art of programming.