How to be a Rookie

I’ve been slinging code for a long time now. I had my first gig for pay back in 1996 and with a couple small exceptions, I’ve been telling computers what to do since. But for the past year or so, I’ve been a rookie all over again.

November before last, the company I worked for merged with another. After a few months, my baby turned into a proper application and got pushed out the door.

I moved on, getting a new project in a language and toolkit I hadn’t used since college, on top of a database system I’d never used in anger. Similar to what I’d used in the past? Sure, but the devil is in the details. Knowing your way around a system is a big part of what separates the efficient programmer from the rookie.

I was a rookie again.

Now, I’ve done this a few times, and I think most programmers who’ve been around for a while have too. Times change, frameworks come and go; you either learn and adapt or your spend the rest of your days maintaining someone else’s legacy. Thankfully no one has really come up with anything new in computing since the 1960s, so all the different systems are built on similar bones. I find the learning curve for each new system is a little shallower than the one that came before, though some jumps are harder than others. Learning good JavaScript was mind bending, as were C++ templates.

Being a rookie again is frustrating; I feel like I’m moving in molasses. Tasks that should take an hour end up taking a day. I find that this is rarely because of a lack of understanding with the language, but instead a lack of experience with the tooling and frameworks used to build a proper application. Every programming environment has a language at it’s core, but the truly distinguishing features are the frameworks and tools around the language that let you create useful applications.

When I’m a rookie, I want to become proficient as fast as I can. To that end, I always try to find a guide or a mentor, someone already proficient in the thing I’m learning. A good guide will help you to efficiently use what the framework provides and steer you around the potholes and pits of certain death. Have them review your code and your architecture, as often as possible. Make sure they know you’re treating them as a mentor, otherwise they might get a bit annoyed with the constant review.

I also write down what I’m learning. Just quick notes in a notebook is plenty, or I’ll keep a blog. Writing things down helps me to remember what I learned. Something about forcing the knowledge out of my head and out onto the page helps me internalize the lesson. Things I write down, I remember for years. Things I don’t I seem to quickly forgot.

Next, I try to teach what I just learned to someone else. Teaching is the best way to make sure you fully understand something. To teach, you have to really wrap your head around a thing, so much that you can explain it in words and pictures to something else.

If I keep that up, I find I’m out of rookie land pretty quickly.