- This is the last of three posts about art and code, specifically about the similarities in chronological flow/process. I recommend reading the first post and second post prior to this one.
- These are subjective views/opinions/not facts and are from the perspective of a novice programmer and visual artist.
- This topic deserves a much longer extrapolation and could easily become a book. These posts will be fairly concise.
- This preface appears at the beginning of each post in the series.
- I am passionate about this topic and believe there are far more similarities than differences in artistic and technical pursuits. I am, overall, at a loss as to why the two generally are held up in contrast to each other.
It’s over, or almost over. The thing will be done soon.
For me, this part of the art-making and coding process is the most nerve-wracking. This is when I have to wrap things up, make them final, and commit to (sometimes temporary) permanence. And once it’s done, I put it out there for folks to look at, use, wish there was more to, or find faults with.
But at the of the day (and the project), the bright side of not working on this thing anymore outweighs any of that.
This part of the process often contains the following actions or thoughts.
The final touches for both art and code usually involve tying up loose ends and cleaning up after the mess of creative flow. Because it can be a messy business. Below are examples of the finishing touches, all the way to actually being finished.
- Linting | cleaning up the area and taking care of used materials. Tying up loose ends.
- Unit tests (I mean, these should probably be written already) | preserving the work (spraying, coating), matting and framing. Making sure it can withstand at least some stressors.
- Documentation | a description/title. Ensuring the work is comprehensible to others.
- Making a PR or publishing the project | hanging it on a wall. Putting it out there.
- Peer review | hanging it on a wall in a gallery that the whole world can walk into. Putting it out there.
With both art and code, one has to actively consider a number of factors through the lens of time. Most notably, time decay and environmental stressors.
Once the thing is created, unless the creator takes steps to ameliorate this, time decay inevitably sets in. Things, once created, capture techniques and technologies that exist or were popular at that point in time.
- Languages, syntax of languages, tools, that version of x | colors, brush strokes, shapes, methods/schools
Here’s an architecture example. (Forgive me architects, this is not a perfectly 1:1 analogy and I don’t intend to communicate that these buildings are equivalent in their architectural significance.)
They both need to be maintained. They both have different maintenance needs. They both have their charms. They are maybe not so charming to some people. Either way, they need to be taken care of. This is as it is with art and code.
Time decay involves environmental stressors. Examples:
- If the art piece is exposed to the elements, its materials will degrade.
- If the coding project is not kept up to date, security vulnerabilities crop up and as the whole world of technology keeps moving forward, things can start breaking.
- The public uses it | the public sees it. Yikes. Wear and tear occurs. Users and viewers experience it in ways they perhaps were never intended to experience it.
This is my favorite part of the painful process.
It is an opportunity to reflect and effectively do a postmortem on one’s own process. This is when we notice areas for improvements and have a chance to learn from ourselves and the effort expended on the creation.
This is also a delicate part of the process, because it is far too easy to start comparing. The final product to the original idea, the final product to other people’s work, etc.
Ideally, we come out of the reflection period with a general sense of accomplishment. Here are some techniques I’ve used to reflect productively:
- Pretend I am mentoring the 8-year old version of myself and openly self-dialogue about how things went (hey, not for everybody, but it works for me)
- Timebox your reflection (e.g. 80 minutes)
- Ask “what really worked for me?”
- Ask “what really didn’t work for me?”
- Ask “what will I bring forward into my next art or code effort that will help me enjoy the process more?”
I have baked this reflection phase into each of my coding projects. I list what I have learned in the README of each project I post on Github. I blog about my projects. It’s all part of documenting the things I learn, so I don’t have to learn them the extra-hard way (again). This is a powerful opportunity to collect data on oneself; data that can be leveraged to gain greater heights in the future.
In my experience, there are two big feelings at this part of the process.
Crushing perfectionism and self-doubt typically go hand and hand and typically are manifestations of imposter syndrome. Learn more about Imposter Syndrome from the APA.
Impatience – I’m done. When will it be over?
Feelings happen. They have has much power as I allow them to have over this part of the process.
“To iterate or not to iterate?” – that is the question.
- Do you want to do it again, only better?
- Are there ways you could build off of this?