Professional code vs art code

#art

I've been recently asked about my process for creating generative art. To be honest, I've never given it much thought before, but after mulling it over, I've decided to write it up for future reference.

This post is not intended as a primer for generative art, it's more of a collection of my thought on the matter. If you want to learn more about it I will point you in the direction of much more profilic artists like: Tyler Hobbs or Matt Deslauriers or if resonate with videos more, you should check out Dan Catt youtube channel.

Anyway, if you are interested in my insights into the subject please read on :)

Professional Code: Conventional Wisdom

Few years ago I've read an interesting article about differences between amateur and professional software and it's conclusions stayed with me. The main idea behind it is the fact that quality of code should be evaluated together with the reason for the code to exist.

Most developers are familiar with what is considered a good code written in a professional setting. We can produce a lengthy list of desired features:

If code breaks many or most of these points, it's ofter considered "bad code". But is it really?

What is the main reason for code to exists?

Of course, if your goal is to build the next Facebook and you start by writing poorly architected, untested, undocumented code with non-deterministic builds, you're going to have a bad time. But that assumes you intend to support the codebase in the future.

What if I told you that you could call code similar to the one described above "good" if you change its purpose?

Art Code: A Different Paradigm

I'll define art code as code written with the primary purpose of generating art - this is its main goal and everything else is secondary.

It's important to note that I'm not advocating for writing sloppy code for the sake of it. Rather, I'm suggesting we keep in mind the main objective and learn to compromise on aspects drilled into us by day-to-day development work.

Correctness is not always good (or even desirable)

In the realm of generative art, code that generates great-looking results but horribly breaks 1 in 5 times can be considered "better" than proper code that works 100% of the time but generates bland results.

Coding mistakes can lead to unexpected and beautiful results. In the image below I've made the mistake in mathematic formula calculation resulting in skewing of the plot to one side. Because of that final piece looks more organic and interesting.

Tool for exploration

Writing art code can be viewed as an exploration of unknown space of possibilities. That's why it's important to keep the code flexible and open to rapid changes. Unlike in professional setting where stability is key, in generative art, the ability to quickly pivot and experiment is crucial. You should embrace things like copy-pasting code, hardcoding values and similar normally frown upon techniques.

Only constant is change

In generative art, change is not just inevitable - it's desirable. For me this is the biggest struggle - many time I've been down the rabbit hole of overengineering piece of code only to find out that I want to completely change it the second I'm done with my proper implementation.

No one will need to maintain your code

In most cases once you are done with particular art piece the code will never be modified again. Sure, you might ocassionally get back to it to reference something, or remix it into something new. But even then if you are unsure how something has been created it can lead to unexpected results. And like I tried to convey earlier - unexpected is good.

Ready to try?

I really think that you owe yourself to try creating some generative art. It's definately a different experience than churning out CRUD apps that you spend so many hours per week. If you need more convincing, I've tried to expand on that point in my follow-up article, so you can check it out.