Painters & Hackers
Hacking1 and painting2 are both hobbies for me. I write programs for myself, to make things easier or just because they are fun to write. Few of these programs are useful3. More often I write useless programs, like a program to determine if random squiggles generate random numbers4. I started painting and coding about fifteen years ago5 for my own enjoyment. Along the way, though I’ve found some interesting comparisons about the reception of paintings and programs and whats it like to interact with other hackers and painters.
There are many similarities between hacking and painting. Actually, I find the similarities are little boring because a similarity means that there is no real reason to take up both hacking and painting because you could theoretically derive the useful characteristics by just taking up just one. I agree with similarities outlined in Paul Graham’s book Hackers & Painters6 - that both hackers and painters use past references to learn from - museums for painters, and open-source repos for hackers. Also, both hacking and painting require learning by doing, rather than by reading. Both require building on what you’ve done previously, although I don’t think this is specific to just painting and programming. Both also generally require developing the final product through gradual refinement.
The differences between hacking and painting are a lot more exciting, as they reveal the potential benefits of one activity versus the other, as well as where one activity has deficiencies. In painting, mistakes can often be incorporated to yield even better results, whereas in programming, a mistake often begets more mistakes. In painting, you are dealing with the brain which is quite sophisticated in specific areas, like recognizing faces which means that some aspects of a painting which require only a speck of paint (the iris, the curve of a mouth) will make or break the painting. In this sense, the painter has it harder because they have to deal with sporadic episodes requiring surgical precision.
In terms of general reception, though, I think the hacker might have it harder than the painter. One big difference between hackers and painters is who the audience is. In both cases, the audience is human, but the number of humans who make up that audience is different. In painting, the audience is often a single person. The majority of paintings in the world do not hang in museums seen by millions - the majority of paintings hang in homes and are placed their by only a single person who thought it was beautiful enough to purchase, to send to their friend, or create themselves. In contrast, for hackers, the audience is anyone who can download your code which, thanks to Github/Gitlab/Bitbucket, can be hundreds and thousands of people. This difference in audiences becomes a problem for the public perception of writing programs. When I tell someone I’m coding a silly program, like writing a program to use squiggles to validate random numbers, I often get a reaction like Why would you do that?, presumably because they imagine how little impact that would make on the huge audience. Alternatively, if I tell someone I’m going to paint a silly picture, like a bunch of squiggles, the reaction is more like Cool, very avante-garde because they realize that there is one person out there who would love such a thing. It seems to me that painters, and not programmers, have the benefit of having their motivation be sacrosanct because only one person need find it useful. Put another way, it seems that since coding can yield useful things for many people, it must always be put to use in a useful way for many people. However, I don’t let this stop me and I hope it doesn’t stop you.
Another big difference is that, in painting, the proof is in the eating of the pudding. If the painting is beautiful to the audience (which can be a single person), then it is a success and there is not much to critique. Whereas, in programming, even though a program works and does what is is designed to do, it remains open to criticism in ways that don’t relate to its functionality, e.g. whether it uses the right VCS, or is written in an idiomatic way.7 For some reason, in programming, the proof is not only in the eating of the pudding but also the steps leading up to the creation of the pudding. I think that this is because a painting is to be enjoyed, whereas coding is often to be used (and enjoyed hopefully too). So while most paintings are judged by what they are, programs are often judged by what they are and by what they are not. No programmer ever says to another, This is not missing any features! Instead, the community of open-source programmers often utilize (or abuse) the conduits of communication, creating “issues” that are just features for their own use.
These differences in painting versus hacking leads me to a sour aspect of the of being a hacker in the open-source community. The majority of painters enjoy creating without a narrow definition of motivation and their creations are enjoyed unconditionally by the painting community. Programmers who enter the open-source community may find that they should be motivated to only create what is useful, make it written well, and then support the code to the feature requests of others. I love the open-source community (its far superior to the research community) but I am frequently pummeled by bad apples for not giving them free help or integrating the features they want or fixing the bugs they want. For example, one recent bad apple posed as a Github user but actually worked at a company requested a feature, and when I said I would integrate it at a reasonable fee to their company they responded You should be the one paying me (presumably for providing the feature idea?). What if there was a Github for paintings where you would “fork” and literally get a free painting? That would be amazing, and I would be so appreciative of that. That’s what hackers have right now, but I often see a huge lack of gratitude or appreciation (actually I frequently experience the opposite).
Currently being a painter is more enjoyable than being a hacker. I wish that the opposite should be true since hackers, and not painters, can easily push and pull contributions onto the same project and create collaborations with the click of a mouse. However, This push and pull of the open-source community runs on gratitude, of which there is not quite enough to keep it running smoothly. To keep it running, I hope that hackers can find more ways to begin their interactions with a Thanks: thanks for writing the code, thanks for providing a PR, thanks for the idea, etc. There is even a program to do that: https://saythanks.io/.
- See my github. [return]
- See my paintings. [return]
- Maybe my most useful program: FIND3. [return]
- I was trying to figure out if I could skip using dice. [return]
- One of my first programs, written in 2003 was a band name generator. [return]
- Hackers & Painters by Paul Graham. [return]
- Quote from a friendly critiquer about a recent program I wrote: ”…certainly works, and is race-free, but it is non-idiomatic.” [return]
29 April 2018. Categories: coding, painting, thoughts.