One of the neat ideas I've stolen from Kent Beck is the idea of coding études. Now, I don't think I do the same thing that Kent does, but the term has stuck with me ever since he first introduced it at an early XP conference.

Okay, so what's an étude? It's an exercise designed to improve technical skill through repetition. It's a musical term, but I use them for improving software development skill instead.

Most of my études are daily half-hour exercises. They're very effective, and teams love them. (There are several examples of this variety in our book.) There's another kind, though, that you try right now. I'm going to give you two of my favorites.

For these études, just start following the étude's rule in your everyday work and keep going for a month or longer. (At least a week, anyway! You'll get more out of it if you do it longer.) Every so often, at least once a week, take a look at how the étude is affecting your work. Think back on how it's changed your code, what you're enjoying and finding difficult, which changes have been positive and which have been negative, and what lessons you should apply after you finish the étude. If you're practicing the étude as a team, you can do this as a team discussion.

These études work best when you're really anal about following the rules. Yes, sometimes that leads to silly or inefficient results. That's okay. The point is to learn, so keep an open mind about what's possible when you take an idea to the extreme. But don't turn off your brain; aim for the best possible result while still following the rule exactly.

Ready? Here they are:

Toxic V

The purpose of this étude is to help you notice and master your use of abstractions. Here's how it works.

From now until the end of the étude, never use the paste command while coding. Think of the V key as filled with toxic sludge, waiting to jab you as soon as you press "Paste."

The point here is to help you notice and avoid code duplication. You can still duplicate code, but to do so, you have to type it all in again by hand. That's a pain in the butt... and that's the point. Use the pain as a signal that you need to come up with a better abstraction. How can you improve your design to avoid the pain?

Killer Comments

This étude helps you improve the expressiveness of your code. Here it is:

From now until the end of the étude, don't write any new comments. Imagine that each comment is waiting to betray you as soon as your back is turned. But! Your code has to communicate just as clearly without comments as it did with them.

The point of this one is to help you identify new ways of writing high-quality, readable code. To get the most out of this étude, get feedback on the readability of your code by pair programming or conducting code reviews.

This étude is harder than it looks. Don't get lazy--be sure that every idea you would have expressed in a comment is still expressed in code somehow.

Further Reading

Dave Thomas explores the same idea from a different angle with Code Katas.