Craft over Art
Always Useful, Sometimes Beautiful
What is code to you? Is it a tool? A way to make your thoughts executable? Something beautiful perhaps?
Over the years, I've noticed that not all programmers look at code the same way. Some see it as a means to an end - a way to solve a problem. Others, like me, think code also holds aesthetic value. I can appreciate elegant code and find it beautiful.
This raises the question, which perspective is right?
I don't think either is correct. We're probably best off somewhere in the middle. I've seen code written purely to get a job done. It did, but nobody was able to work with it after. I've also seen people gold-plate solutions, endlessly polishing their solution while spending precious time and money.
Ultimately, the code we write professionally should always add value - be useful. If we can make it beautiful along the way, that's great, but it's not a necessity. Constraints such as time, money, urgency, and longevity of the solution all influence whether we should invest time in improving code. It's a tradeoff.
We can have different views on what good code looks like. We might have different takes on "good enough." However, we can develop this judgment and make the tradeoff more deliberate. Kent Beck's excellent book Tidy First explains how to make this tradeoff and is a great resource to improve this skill.
As for me, I used to be on the "art" side of the spectrum. I could spend ages going back and forth until things were "just right." Part of the reason might be that I didn't start programming to make my life easier. I never wrote scripts to solve my problems. I started my programming days at university, where much of what we learned was abstract and felt far removed from solving practical problems.
I envy the pragmatic ones. Those who've developed an appreciation for programming because of the incredible problem-solving potential. This realization gradually dawned on me, but only after years of modeling and solving problems without value. Unfortunately, I had to light my own fire instead of it being set ablaze in a sudden epiphany of the limitless potential of software.
These days, I try to consciously nudge myself towards the middle of the spectrum by posing myself questions like:
How much value will this bring?
Could I spend my time better?
Is this good enough?
It helps me keep effort proportional to the payoffs.
If you're on the opposite end of the spectrum, questions such as these might help:
Is this understandable for others?
Could we continue working on this with reasonable effort?
What would improve this the most at what effort?
We might not be able to change our modus operandi, but we can always improve the result with some awareness.
The book Apprenticeship Patterns has a chapter called Craft over Art, which inspired the title of this post. One sentence left a lasting impression on me. Hopefully, it will do so for you, too.
Code can be beautiful, but must always be useful