The Rules of Art and Work
The topic of “code as art” nearly always devolves into a question of “What is Art anyway?” which in turn devolves into philosophical grumbling and mumbling.
Let’s see if we can strike at the root of this question once and for all, by using a simple and minimally controversial heuristic. Ready? Here we go!
See these little fellas down here?
Suppose that you were the one who made this scene. If you did it because you just really love putting little construction workers all over your sugary treats, and it makes you feel good, and you’d prefer to call it Art, well then… it’s Art!!! No problems there.
If on the other hand you built this little tableau to make some sort of social statement about the plight of workers, or because someone commissioned you to build a work entitled “What if Willy Wonka’s factory was everywhere?”–then it’s also Art. It may be successful or unsuccessful, but it’s still 100% safe to say “I AM THE ARTIST WHO CREATED THIS MASTERPIECE OF CHOCOLATE WONDER.”
So far, two for two.
But now consider this third case: You promised someone that you’d buy them a chocolate bar. And when you delivered it to them, you delivered it as shown above. Is that Art? Maybe. Is it a reasonable way to deliver on your promise? Probably not.
And this is the conundrum. As programmers, we usually serve people with a job-to-be-done. If we put our own pursuit of art ahead of the needs of our customers, then we let down our customers and also (unless the act of doing so is some cruel form of performance art in itself) end up letting ourselves down too.
So the bottom line is: Anything can be art, if you squint at it hard enough. But your artistic efforts in a professional setting are constrained by the purpose of the product or service you’re working on, and the needs of the customers you serve.
If you can delight people with artistic expression while still getting your job done, great!
But don’t make that the main goal unless Art is the actual thing the customer is paying for.