How Art School Prepared Me for Programming

At the startup where I work, a lot of my coworkers in the engineering department have great stories about where they came from - organic chemistry, education, computer science, publishing, data, etc. - the list goes on. My personal experience before transitioning into software was in traditional illustration: mostly pastels, oils, and acrylics.

While I don't normally catch flack for having a non-traditional background, I know a few folks who associate art solely with emotional expression, and technology exclusively with math and logic. I'm of the opinion that programming is as much an art as it is a science or a utility. In that vein, I wanted to share a few lessons I learned in art school, but use in my job every day.

You can often communicate better through abstraction.

When I mention "abstract art," a lot of folks bring up Jackson Pollock, Mondrian, or some of the more "out-there" (read: usually cubist) works of Pablo Picasso. Personally, I'm really digging this quote I saw highlighted on Mondrian's page (linked above):

"I wish to approach truth as closely as is possible, and therefore I abstract everything until I arrive at the fundamental quality of objects."

That idea is extremely appealing to me as a developer - the idea that I could strip away all the unnecessary details in a project until only the bare, beautiful, unconvoluted minimum remains. The less code there is in a project, the cleaner the lines of the whole; the simpler the shapes, the less muddied the colors. This doesn't mean there's a "right" number of lines or characters or methods for a project to have; only that I strive for elegance through simplicity (actually achieving that admittedly lofty goal is another matter 😁).

As a pixel artist, I think about abstraction a lot - how much detail can I take away before my doodle becomes unreadable? What's important to include? I ask the same questions when I'm designing an interface for a class or when I'm writing documentation. I think (a lot 😳) about how much flexibility to allow for - how much configuration is too much? Not enough? How much complexity can I abstract away while maintaining the functionality and usefulness of a service? Documentation is hard, too - distilling nebulous chunks of shared and individual knowledge down into a manageable set of bullet points, examples, and/or diagrams is an art form all its own.

The same concept holds true when you're trying to explain something verbally. Choosing the right level of detail for your audience - whether it's your co-workers or a class of programming newbies - allows you to communicate with them clearly.

We sometimes talk about libraries or workflows as "black boxes" - I think this is a valuable tool and a great abstraction for working with beginners as well as experienced folks. It's nice to remember sometimes that we don't need to know how everything works right now - we can give ourselves the luxury of tighter focus on what we're doing.

Don't be precious with your creations.

There's a story that circulates through the students and alumni of my alma mater of one instructor's particularly challenging drawing class. For an entire semester, students work in pencil on paper, drawing the same model in the same pose for six hours a week. They pour their hearts and souls into this drawing, obsessing over light, form, and subtle gradations of shadow for months. At the end of the class, after a group critique, the instructor gives his final instruction:

"Erase it."

After all that hard work, the students rub out every painstaking pencil stroke until their papers are gray and featureless. Some call it cruel (I won't say it's not, honestly), but it teaches a very important lesson in an indelible way. Don't be precious with the product of your work - the important thing is that you did it. You've learned from the experience and (as the instructor would say) - "You drew it once, you can draw it again."

This idea has served me well in my work as a developer, from being critiqued in code reviews to seeing thousands of lines I wrote deleted from a project all in one fell swoop. You'll hear folks say "You are not your code!" and it's true! The amount of amazing (and sometimes bizarre) knowledge I've gained from my past work is invaluable to me regardless of where it lives now. When someone points out a strange pattern or opportunity for improvement in my work, I have no compunctions about erasing my old "sketches" in favor of a better solution.

Dissatisfaction with your work is a sign of developing taste.

This one is very close to my heart. When I was in art school, I noticed a pattern in how I felt about my work:

1. I'd work really hard and create some pieces I was super proud of.
2. I'd see the amazing work that my peers, mentors, or even famous artists created and start comparing my own output to theirs.
3. Cue depression and dissatisfaction with my own work - everything I'd done before was childish and crude; my hands weren't capable of creating what I saw inside my head.
4. After days/weeks/months of struggling with my own skill level, I'd start to create things I was proud of again.

This probably sounds familiar to anyone who's learned how to code - at least, it was common among my students when I taught web development. One of my drawing teachers told me that taste and skill develop at different speeds, and at different times. If you can't see the flaws in your work, then you probably need to refine and develop your skill further. If you feel that what you've created is lacking, then your level of taste has simply progressed beyond your current level of ability. Thinking like this has helped me deal better with doubt and (mostly) fend off the dreaded impostor syndrome.

Thank you for reading! If you've got any other stories of lessons you brought to your tech job from a seemingly unrelated field, I'd love to hear them.