The Null Device

Dabblers and Blowhards

Hacker and painter Maciej Ceglowski calls bullshit on Paul Graham's Hackers and Painters, claiming that the two occupations have no more in common than hackers and, say, pastry chefs, and that Graham's essay is basically an attempt to appropriate a sexier and more romantic image by hand-waving and sophistry:
Great paintings, for example, get you laid in a way that great computer programs never do. Even not-so-great paintings - in fact, any slapdash attempt at splashing paint onto a surface - will get you laid more than writing software, especially if you have the slightest hint of being a tortured, brooding soul about you. For evidence of this I would point to my college classmate Henning, who was a Swedish double art/theatre major and on most days could barely walk.
Also remark that in painting, many of the women whose pants you are trying to get into aren't even wearing pants to begin with. Your job as a painter consists of staring at naked women, for as long as you wish, and this day in and day out through the course of a many-decades-long career. Not even rock musicians have been as successful in reducing the process to its fundamental, exhilirating essence.
It's no surprise, then, that a computer programmer would want to bask in some of the peripheral coolness that comes with painting, especially when he has an axe to grind about his own work being 'mere engineering'.

Ceglowski puts the blame for Hackers and Painters, and the whole genre on the obvious suspects:

I blame Eric Raymond and to a lesser extent Dave Winer for bringing this kind of schlock writing onto the Internet. Raymond is the original perpetrator of the "what is a hacker?" essay, in which you quickly begin to understand that a hacker is someone who resembles Eric Raymond. Dave Winer has recently and mercifully moved his essays off to audio, but you can still hear him snorfling cashew nuts and talking at length about what it means to be a blogger[7] . These essays and this writing style are tempting to people outside the subculture at hand because of their engaging personal tone and idiosyncratic, insider's view. But after a while, you begin to notice that all the essays are an elaborate set of mirrors set up to reflect different facets of the author, in a big distributed act of participatory narcissism.

Disclaimer: I'm currently halfway through Hackers and Painters; so far, I've found it interesting in a big-ideas sort of way. Though I am as yet undecided on whether the emperor is actually clothed, and whether Graham is a visionary master, a self-important blowhard or a bit of both. (One could perhaps count it in Graham's defense that Ceglowski admits to being a Perl programmer, but I digress.)

There are 4 comments on "Dabblers and Blowhards":

Posted by: datakid http:// Mon Apr 18 22:29:41 2005

what's wrong with programming perl? Personally, Ionly use punch cards....

Posted by: toby http:// Mon Apr 18 23:12:14 2005

To borrow the form of Maciej's arguments: So programming isn't like painting because it doesn't get you laid? Is, painting, therefore, like being a prostitute?

I think the only really useful point that can be made about hackers and painters (and just about anyone, in fact) is that the most successful people use both sides of their brains to do what they do.

Posted by: acb http://dev.null.org/ Mon Apr 18 23:38:50 2005

I believe the gist of it is:

Paul Graham: hackers aren't like scientists or engineers but more like painters. I'm a hacker and a painter, and this is how I see it.

Maciej Ceglowski: Hackers aren't like painters because no matter how good a hacker you are, it'll will never be cool enough to get you laid. PS: you're a wanker.

Though yes, Toby, you're spot-on about both sides of the brain.

Posted by: acb http://dev.null.org/ Mon Apr 18 23:41:03 2005

As for Perl, one of Graham's theses is that languages that make programmers deal with nasty little problems cramp their style and stunt their development. Perl could be said to be one such language; the mental resources devoted to keeping track of all the rules and special cases and nifty multiple ways of doing things are resources taken away from assembling elegant structures of code.

I've written major projects in Perl and Python, and my experience supports this view.