Okay, I’ll bite.

This post is part of a weekly Blog Battle started by some of my coworkers. The idea is that each week, a title is chosen and everyone writes a post based on not a topic, but just the title, and let each author interpret it in his own way. The title for this week is “Get Better”.

I’ve been reading the book The Passionate Programmer by Chad Fowler, which includes a chapter called “Practice, Practice, Practice.” In it, he makes a good point - that programmers tend to practice on the job.

In any profession involving performance (like music or sports), the professionals practice out of sight of their audience. They practice to get better. They push their limits and try things they’ve never tried before. When they try those things for the first time, they suck! The football player misses the catch trying out that new complicated play; the baseball pitcher misses the strike zone by a lot when trying out the knuckleball for the first time; the music sounds downright awful when the jazz musician is trying to invent a new riff.

And when those professionals get on stage or when they take the field, you can be damn sure they’ve practiced beyond their limits what they’re about to perform for their audience and that it’s (likely) going to look or sound good.

But the majority of software developers do their practicing on the job. They get better all the time, but they make their mistakes during their performances. This is a major source of buggy software.

I know I’ve been guilty of this. My first project here at SEP was on a Perl-based web app. I had never tried anything even remotely like Perl before. I jumped in, but I didn’t try learning Perl outside of work. And I admit, my first “masterpiece” is not something I’m proud of. Fortunately, that whole system is being rewritten and soon my code will no longer have to be maintained by people just a few steps away from me.

Now when I learn that I’m going to be doing something new at work, I try to learn as much as I can beforehand. I was going to be put on an Android project not too long ago, so I bought myself a book to learn the ins and outs of Android programming. I spent some of my own time writing little apps to try new things out. And it definitely helped. I didn’t diddle around on company time trying to figure out how to write “Hello, World” on my smartphone. My time was actually valuable to the company. Plus I was enjoying work a lot more.

Fowler suggests taking a look at the to-do list for your favorite piece of open source software and implementing one of the needed features or fixing some bugs as practice. This way, not only do you learn whatever programming language or API that software is written in, you also learn how to get up to speed on an existing project that you may suddenly get put on. And not only that, but you get to work on some of your favorite software as well!

So the lesson in all of this is that practice makes perfect. But only when you push your limits can you become better during your normal performance. If you make your mistakes when they won’t matter, then you’ll get better for when it does matter.