What Art School Taught Me About Building Software

Back in the day, I was really into art. I’d spend lunches in high school painting in the art room while I ate. Then, I went to Savannah College of Art and Design to study computer art, which was mostly 3D animation. For the most part, I have not used the specific skills I acquired in art toward building software, with one notable exception.

I build software the way that I was taught to draw and paint. My first goal with software is always to create a sketch. That usually looks like some specs, or a rough test plan. From that sketch, I can take a step back and get other people’s opinions. Then I refine the sketch and create a prototype. The prototype is another chance to step back and review. Then I commit to the sketch and start filling in the parts.[1]

When most artists fill in sections of a painting, they move from place to place, not focusing too much on one spot for too long. When you focus on one spot too much, you lose track of the composition. When you lose track of the composition, you lose opportunities to make improvements to the whole by making small changes in different spots. You have to step back frequently and consider not just what you are working on, but what it’s purpose is. By moving around frequently, you reduce the risk that decisions in one area will have a negative impact on another area.

This isn’t a set of practices, this is a philosophy. Move your focus around, seek balance, reduce risk, don’t overwork things. Software is an art, so treat it like one.

[1] I’ve tried using different methods at each step and found it mostly doesn’t matter what the method is as long as the fidelity is appropriate for each stage.