Practicing Programming On the Job

—Andy Hunt

04/24/2003
Published in Andy's Blog

Reader Alison Fish comments on these emerging ideas of practice, performance, music and programming:

I think where I get stuck is that I can never justify practicing as a programmer where I could as a musician. As a musician I’d practice to sharpen the performance, the performance is what pays the bills. As a programmer the performance is all of the time, nine to five… So how can you justify practicing when you should be performing?

An excellent question. Sports teams get scrimmages before the big game, musicians get to “woodshed” parts before the concert, and so on. As programmers, we are not given that opportunity. It’s as if we’re dropped in the middle of the Superbowl and don’t even know the name of the other team, or how our own team works together. We don’t get a chance to practice, in that sense.

But what do novelists do? They make scrap paper: they write drafts, knowing that they are drafts. This gives them a certain freedom to experiment with character and plot, but not necessarily commit to it. If the draft doesn’t feel like it’s going anywhere, it goes in the trash. If it has potential, it gets refined and reworked into a more polished piece, and eventually morphs its way into the final product. This starts to blur the line a little between practice and performance, which we can take advantage of.

Practice for us must be part of performance. Now there are two ways to go about this. One is to make deliberate practice time to try out things unrelated to the current project. That’s a reasonable thing to do, maybe not every day, but certainly every once in a while. Something like Dave’s Kata exercises would be helpful here, but you are quite blatently taking time away from production to do it.

The other way is to practice “as you go”, using the real project and your real assignment. The writer suceeds because the first thing he or she writes is a draft; there’s an implicit “permission to fail” there, which grants the creative mind a wonderful freedom. It might not work out, and that’s okay. Just as with novelists, programming is not about getting it right the first time—it’s about getting it right the last time.

Unit tests can really help you work in this manner. By writing the test first, as XP advocates, you’ve set your baseline. Now you have permission to fail, to practice, to try out whatever crazy thing you can think of that acheives the goal of getting the test to pass. Once the test passes, you’re not done. You can still practice—is the code as cleanly refactored as it could be? Can I make it any better? Yes, up to a point. You don’t want to spend a huge amount of time polishing and playing with the code, but you can spend some time trying out a few “what-if” scenarios: What if I had implemented this differently? Would it be better this way? You can do this sorts of practice runs safely because you’ve got unit tests and version control in place (you do have unit tests and version control in place, right?) If it doesn’t make the code better, throw it out. You’ve learned from the experience (which is what practice is all about), and you can justify the effort directly in terms of potential benefit to the code at hand.

Practicing is really just a frame of mind, after all: working out the hard stuff without having to save the results.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.