The other day I showed a fellow programmer an old blogging engine I had built quite a few years ago. He was shocked by how much work I had put into the code and as we went through one feature after another, he kept asking me why I had added it since it didn’t look like I had ever actually used the feature.

He’s right, of course, it turns out I wasn’t much for using pingbacks or trackbacks, and my infrequent posting¹ meant no one ever commented on my blog, so they couldn’t appreciate the time I spent getting the interaction just right. But I learned a ton about how all those things worked during the nights and weekends I spent crafting that code. I also learned how to read and implement specifications during that time. I became a better programmer through reinventing the blogging wheel.

I love reinventing the wheel, I also love iterating on my previous solutions to make them even better. Luckily, I seem to be in good company with this compulsion, here’s Charles Moore, the creator of Forth, on reinvention:

Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it .

and here’s a description of Forth’s relentless iteration on his own code:

Moreover, he was never satisfied with his own solutions to problems. Revisiting a computer or an application after a few years, he often re-wrote key code routines. He never re-used his own code without re-examining it for possible improvements.

One of the things I love most about programming is the deliberate practice it entails, and with wonderful things like Github and Stack Overflow I’m not even sure it’s all that difficult to get started anymore. You can look at how better programmers have solved the same or similar problem and use their code as a template to roll your own solution. Joshua Froer, in Moonwalking with Einstein, uses Benjamin Franklin to describe deliberate practice:

Benjamin Franklin was apparently an early practitioner of this technique. In his autobiography, he describes how he used to read essays by the great thinkers and try to reconstruct the author’s arguments according to Franklin’s own logic. He’d then open up the essay and compare his reconstruction to the original words to see how his own chain of thinking stacked up against the master’s.

This is also similar to how chess masters improve their skill, Joshua continues:

“The best chess players follow a similar strategy. They will often spend several hours a day replaying the games of grand masters one move at a time, trying to understand the expert’s thinking at each step. Indeed, the single best predictor of an individual’s chess skill is not the amount of chess he’s played against opponents, but rather the amount of time he’s spent sitting alone working through old games.”

Sadly, even thought this is one of the things I love most about programming, it is also one of the things most frowned upon in programming, which is strange, since tons of things rely on this type of deliberate practice for improvement, no one complains when a musician covers a popular song, or an artist paints a picture of fruit, or a poet writes a poem about love. And yet, lots of programmers seem to relish pointing out how much time you’ve wasted on reinventing the wheel.

The other day, while working on my new blogging engine that powers this very blog, I decided I wasn't going to reinvent the wheel with the RSS feed generation. I spent a few hours trying out a few available libraries, but they all proved frustrating to install and/or use, relying on a ton of complicated xml dependencies and trying to be all things to all people. Throwing my hands up in frustration, I ended up rolling my own solution in about 30 minutes, how was I able to reinvent the RSS wheel so fast? Because I had done it once or twice before, and so I knew how.