Dec 1, 2014
I can’t remember who recommended I read Art & Fear (by David Bayles and Ted Orland), but Sam bought it for me for my birthday last year, and I finally sat down to read it1. From the start, I was struck by how much the authors' perspective on artmaking could just as easily apply to programming. Below are a dozen or so quotations pulled from the book that seem particularly relevant. I think they stand on their own without context, but the whole story is well-worth the price of the book.
I will say: I’m not comfortable drawing terribly stark lines between programming and art. For most programmers, the purpose of making a program is to accomplish something unrelated to the program itself. A finished program4 feels more utilitarian than a finished work of art. And yet, the internal design of a program and its utility are intertwined, particularly with regard to future utility (agility?). Certainly, the internal design is a subject of great interest and frequent debate to those who work on the program, down to the lowest level of abstraction5.
Then there’s the related matter of aesthetics6, which then veers into taxonomy/folksonomy/ontology territory, since identifiers lend to the aesthetic and are notoriously difficult to choose. The conversations around aesthetics and design often feel like conversations about art, even though the end-result is purportedly what really matters. This is to say, programming seems to be both an act of expression and an act of producing something useful, and I think there’s a tension between the two. Jacob Thornton (@fat) has a great post comparing the development of Ratchet and Twitter Bootstrap that explores this angle some more.
Waffling aside, I think there’s a rich vein of ideas at the intersection of programming and art, and I intend to revisit Art & Fear periodically to wrestle with them.
Thanks to Brett Chalupa for feedback on this post and for various conversations around this topic.
To really get a jumpstart on a book, head to your local laundromat and only bring a book, a notebook, and a pencil. Well—that, and some laundry. ↩
I love the “Operation Manual For Not Quitting” which, in short, is: find a group of peers, share your in-progress work with each other, and make that the true “destination” of your work. ↩
Strictly speaking, achieving a result in some language implies that one can achieve that result in any Turing-equivalent language. Still, I think that this sentiment (something-something linguistic relativity) holds true in programming. ↩
Though, what does it mean for a program to be “finished,” anyway? ↩
It is in the design of a codebase that we “declare what is important,” no? ↩
It’s become popular to attempt to settle on an aesthetic and enforce it programmatically, but there’s seemingly always minutae. ↩