Painting Is Similar To Coding

Last week, I spent a few hours discussing the process of constructing art versus constructing code with a friend who is a painter and this is my rambling musings about that conversation.

At first what struck me were the commonalities and differences between painting and programming; specifically XP style programming. He'll start with an idea or emotion that he wants to communicate (UserStory). He'll make a quick sketch of it and, to my surprise, he normally doesn't look at the sketch again (SpikeSolution). Then, he gets started. He mentioned that there is nothing more daunting than a blank canvas. (It's fortunate for us programmers that we rarely start out with a completely blank canvas. In most cases, we have a large toolbox to reach into to begin work. Of course, the difference here is that an artist gets dinged for producing derivative works while we programmers do our best to re-use previous work and ideas.)

He picks some place on the canvas and begins to paint that portion of the image. Unlike XP, he has no formal mechanism for deciding what is the best place to start. From then on, the process is very iterative. He'll paint a piece, step back, look at the overall image, let the painting tell him how it should change in order to achieve the desired effect, rework portions of it, add a little more, step back, and so on until he's satisfied with the result. He spoke very specifically about the painting speaking to him. Oftentimes, he has found that to achieve the effect he was going after, he must throw away entire portions of work because what he thought was the right approach was rejected by the painting (ReFactoring and ListenToTheCode)

At this point, he referred to the concept of ThePartOfYouThatKeepsTrackOfTheBigPicture?. Evidently, there have been times where he spent hours developing the perfect flesh-toned left hand before he realized that he was painting it on a right arm in a specifically non-realistic style of painting. So, he has developed a sense that compares what he is doing to where he his in the painting and the effect he is trying to achieve.

I think there is a similar sense in programming. Ultimately, I think ThePartOfYouThatKeepsTrackOfTheBigPicture? is the sense that you develop from repeatedly applying ListenToTheCode and RefactorMercilessly. Once the nearly infinite ways code could change to implement a new function is narrowed down through the filter of DoTheSimplestThingThatCouldPossiblyWork, I find that many times, there are several candidate approaches. ThePartOfYouThatKeepsTrackOfTheBigPicture? winows down those options to the one that best serves the aesthetic sense of the code as a whole.

According to my friend, just because you know the names of all the paints, brush strokes, and styles does not necessarily give you a coherent big picture. What gives you a coherent big picture is a sense of aesthetics. What gives you the sense of aesthetics is understanding how all the little pieces form together to achieve a purpose. I strongly suspect that there is a parallel in programming, but I can't quite put my finger on what it is.

ThePartOfYouThatKeepsTrackOfTheBigPicture? helps keep track of the MundaneLittleDetails?. When I have a sense of the overall code, I can more easily remember that some thing has been coded somewhere else so I can act on OnceAndOnlyOnce. Knowing the big picture also lets me find that piece more easily. While DesignPatterns provide a vocabulary for talking about the big picture, they don't necessarily convey the aethestics of it. Without the aesthetics, I doubt that the big picture would ever be coherent.

--MarkAddleman

The big picture view becomes more and more firmly planted with experience (of details and big picture interactions), and is what's meant by SoftwareArchitecture.

Paul Graham's "Hackers and Painters" comes to mind after reading this. http://www.paulgraham.com/hp.html

--AnonymousDonor