Beautiful Code?
I remember enjoying Jeff Atwood’s post about “Code isn’t beautiful”. It took me a while explaining to myself why people are chasing after “beautiful code” so much. Why people are so passionate finding or forming beautiful code? Should great painters talk about beautiful colors or beautiful paintbrushes? I always thought they appreciate the entire painting, created and driven from emotions, dreams, ideas, styles and yes — colors & paintbrushes.
Why are we trying to figure out the best paintbrush to use or the best color? Why not trying to figure out the “best all”, the best experience, the best value, the best process?
I would define Beautiful Code as a surface to allow three magic abilities to emerge:
- It should be easy to add new capabilities.
- It should be easy to change existing capabilities.
- It should be easy for new teammate to become productive almost immediately (within 15-30 days).
If you’re able to have these abilities in your painting, your software, then you’re probably doing something beautiful; you probably figured out the correct paintbrushes, the right colors and most important — how to use them wisely to introduce true beauty.
I am not mentioning pseudo-code, language specific or whether or not testing is worthy in my list above. There are many ways to paint beautifully, it is up to you to figure out what makes software beautiful to you and figure out the right tools and processes to achieve it.
Once you do figure it out, please do your team a favor and write it down. Discuss it with them, ask them to do the same. It makes Code Reviews so much easier when you can provide feedback about things like code complexity, using arguments such as #2 and #3 above. It creates a discussion around the greater good of the product and your team, and how this code fits in. It adds context and protect the team’s (and business) interests without taking away the individual’s style.
And style matters. After all, we’re not the damn Borg.
