I’ve written a hundred million lines of code in my lifetime. Okay, that’s an exaggeration, but it sometimes feels like it. So much of what I write is not only obsolete now, it was obsolete by the time the project finished. And that’s a good thing.

The only code without bugs is no code. But the only way to write code? Is to write lots and lots of it. In much the same way as authoring a book or architecting a blueprint, code is the result of errors and revisions. It is imperative for all beginners to do two things: 1. write their own framework, 2. never use their own framework.

Why the dichotomy? Because only when you’ve done something yourself, and found all the holes and gotchas and little edge cases, can you begin to appreciate what is involved in the larger tasks. Frameworks don’t arise because the author was seeking to create The Definitive Perfect System For All Things Ever.

They took what they had done, over and over and over, and codified it into something that managed to take away 80% of that pain.

It always reminds me of an old paper that came out about an art teacher. He split the class into two groups, one had to make a single perfect vase while the others had to make as many as possible. At the end of the semester, the best grades went to those who had focused on quantity, not quality.

And why? Because they’d tried and failed over and over, they learnt what worked, what didn’t and how to improve with each iteration. They didn’t make a thousand ugly vases, just like Edison didn’t make a hundred faulty bulbs. They learnt from each mistake.

So the next time you find a bug, or a better way of doing something take a break and smile. You’re still learning.