An art school lesson

February 2, 2014

The first studio class I attended my first week of college was three-dimensional design. I was extremely nervous, and things started strangely. The professor was absent, and had left a TA who instructed each student to each choose an art postcard from a collection pinned to the wall, with no further guidelines.

Once everyone in the class had chosen a postcard, we were told our assignment was to recreate these paintings in three dimensions. Newspaper and tape were distributed. We had a few hours to put together a rough proposal of our ideas for how to build our projects.

I can’t remember the artist or title of painting I chose, though they were all abstract or stylized in some way that made translating the image to three dimensions challenging.

What I do remember is what the professor said to me once I had hesitantly presented my idea to him: “That looks great. But you should make it twice that size.” A simple suggestion, but an intimidating one for me—I hardly knew how I was going to build this project at all, let alone at a large scale. But he was the professor, so I took his advice.

There wasn’t much for me to do after that except start working, so I did. What I realized is that you don’t have to know how the entire thing is going to come together when you begin something: just start with a small part, learn as you go, and build from there. It wasn’t completely smooth sailing, but my project turned out great, and I felt awesome about making something much more ambitious than I thought I could.

I still think about that experience often when I am starting something new. “Great, but make it bigger!” isn’t useful advice for everyone, but for me, as a person who tends to be more pragmatic and conservative than I need to be, it makes a big difference.

I don’t make ambitious art projects as often anymore, but I find “make it bigger!” applies well to programming, too.

When I started my collaborative drawing app, I barely knew how any of the parts would work. Handling real-time events seemed intimidating, and so did working with TCP sockets. But I figured I could learn enough to build a tiny terminal-based chat, and I did. Once that existed, rewriting what I had using EventMachine seemed straightforward, and then it didn’t seem so difficult to switch to using websockets instead.

Setting a goal that seemed slightly scary and working towards it a small piece at a time got me much farther than I would have thought I could at the beginning. An excellent thing to remember any time a new programming task or skill seems daunting.