I think many of the other "artists" of sorts here can sympathize with this one, even if the field is completely different.

(Warning: long, but hopefully agreeable and understandable rant ahead.)

Designing a program is based initially on a set of large goals and filters down to very small ones. What do you want the program to do when it's finished? Then, what are the big, overarching things that the program obviously needs to do to complete that task? What kinds of things will you need to do for each of those little tasks to happen correctly? How are you going to organize all of these little bits and pieces of functionality so that it makes a lot of good sense, can be expanded, will work reliably, and is very straightforward and simple?

For the cooks in the house, designing a program is, in fact, like devising a recipe on the spot. "Man! Wouldn't it be neat to make a chili turkey meatloaf!" With intuition, you think about the ingredients needed for the coating sauce, and little things like onions, salt, and pepper that would go into the mince. Before starting to cook, you consider the best way to cook everything that would require minimal complication and still taste good.

So, I've spent the past week and a half writing a few hundred lines of code that controls and analyzes the data from a spinning laser beam in order to determine where it's hitting the ceiling, the side walls, the ground, etc. Because it's experimental data, about 30% of it is utter crap at any given time. The bulk of the code is designed to filter out that 30% reliably.

The first problem was that although my overarching goals remained the same, everything underneath was in a turmoil, constantly getting rewritten or trashed (Consider the imagery of a frustrated architect, hunched over his drafting table, with a graveyard of scrunched-up draft paper piling up behind him.) I hadn't gotten far enough with anything to feel remorse at throwing it away.

Finally, when parts of the code started working, those parts would still have flaws here and there, so I wrote more code on top of the working stuff to correct its mistakes, instead of correcting the old code. (This time, consider the imagery of broken patches on old clothes being sewn over by smaller patches, instead of simply replacing the bigger, broken patch.)

This has a psychological effect. Artists experience the same thing when compromising for a slight defect in their work - a stray splatter of paint on what should be a clean city wall in the background of a nearly-complete still-life work, a musical motif that has worked its way deep into the root of a song, but is not particularly catchy or creative. When there is a need to either press on with what is already done, or start over, due to one of these mistakes, the artist encounters difficulty: the considerable amount of work she has done will lose meaning if discarded. In other words, there is a conflict between the desire to preserve and consummate the work that has already been done, and the desire for perfection which requires reversal of momentum and backwards movement in the creative process.

This creative conflict reached a climax for me this afternoon when I realized that although what I wrote worked nearly all the time (and could be further jimmied up to work 100% of the time), I could not bring myself to trust it on its creative merit. I was merely whacking away at the problem until I saw positive results. The realization slammed into me like a mack truck and I felt like shit for the rest of the day.

But having cooled my heels, I realize that if the whole project is going to work out, I will have to trash all this code and start from scratch, now having a much greater understanding of the factors involved in achieving my goal.

Well, I hope that made an ounce of sense to everyone else, but it was therapeutic and self-inspirational for me.

Tags: rants, sun
Current Mood: aggravated
Current Music: John Williams - Augie's Great Municipal Band and End Credits