Software engineering vs. art making

In my very first programming class (FORTRAN) as a freshman in college, the instructor, Mr. Norman, had each of the 25+ students quickly state their name and their major, because he knew that some students were taking it as an elective or out of curiosity and he wanted to gauge his audience for the semester. When my turn came, I said “Art and computer science”. The next student was halfway through his when Mr. Norman interrupted “Whoa, wait a minute! Back up! Art…and…computer science?” There was laughter. An acquaintance who had already read the preface of the textbook piped up “Sure, it says in the book that computer programming is an art!” (This was a FORTRAN text, not The Art of Computer Programming by Donald Knuth. But I digress….) There was more laughter, then Mr. Norman asked “How do you plan to combine those?” I said “I don’t know yet”, he shook his head, and we moved on down the line. I was a bit embarrassed, but I was secretly pleased that my combination was so unusual that this man who had taught dozens of classes and thousands of students was surprised.

At the time, I figured either the art or the computer science would turn out to be too much for me and would fall away. They were both a lot of work with absolutely no overlap in curricula, a lot of hours spent in the computer lab and a lot of hours spent in the studio, but four years later I graduated with both degrees.

I learned there was an emerging field called “computer graphics”, and a light bulb went off in my head. That’s it! That’s where I should be! The intersection of computer science and art! A few years later, with much harder work and much longer hours in the lab, I earned a graduate degree in computer science concentrating in computer graphics. Mind you, this was not using graphics software, this was writing graphics software–the math, the algorithms, the debugging by scrutinizing an output rendered image rather than numbers in a spreadsheet. There was a lot of satisfaction in writing code and then running it and seeing an image emerge.

While I was in grad school, several graphics production companies emerged that were making animation and effects for commercials and movies and creative animated short films. Groundbreaking innovations happened every year and papers about them presented at SIGGRAPH, which I attended as often as I could afford. One of those companies, Pacific Data Images (PDI), became my dream job the day I read that the founder said they actively looked for people that had both an art background and a technical background.

Several years later, I was tremendously lucky to be hired by PDI! I wasn’t creating animation and I wasn’t writing graphics software, but the software I did write supported the animation pipeline. I could have productive conversations with both R&D folks and animators (artists who just happened to use computers), because I knew the vocabulary of both fields. It’s the only place I ever worked where the software was not the product or the mechanism for money-making, it was entirely in support of artists. Buzzword fans like to talk about “synergies”, but PDI really had it: the artists needed to be able to simulate, say, crashing water, so the R&D folks, right there in the same building, figured out how to do that and provide controls so the artists could use it, and in turn the new possibilities excited the artists so they asked for more. They all worked very long hours. Every Friday we saw new and amazing results.

Fast-forward to the present. When someone learns that I had a 40-year career as a software engineer sandwiched between my art efforts, their response is often something like “Wow, so you’re both right-brained and left-brained!” or “Art and software are so completely different, how do you make that work?” I thought about that quite a bit during those decades and especially the past 13 years when I was once again juggling both–working full-time as a software engineer while restarting and ramping up my art, and I figured it out. If you’ve read this far, you’re ready for the answer.

Software engineering and art-making have many of the same characteristics, but have fundamentally different goals. Both require research, tools, problem-solving, creativity, improvisation, testing, redoing, self-motivation, self-discipline, and long hours of solitary concentration. Both produce a sense of satisfaction and accomplishment when the result works well, and a sense of failure and self-doubt when it doesn’t. But software engineering is entirely logical and rational and aims to produce something that does something to help others in some way, while art is personal and emotional—a drive from within that seeks only to satisfy its creator.

So you see, software engineering and art-making are not very different after all! No wonder my work days seem about the same now that I’m a full-time artist.