Review of Hackers and Painters
I recently decided that I needed some technical help and was casting around for a progammer to help me build out parts of the project I've been working on that simply wouldn't get done if I tried to do it all myself. What, asked myself, should I be looking for? What makes a great programer? The question has some real import for me. But that is the topic for another post.
However, in course of researching the question I came upon Paul Graham's 2004 essay on what makes a great hacker. In it he mentions that he'd just written a book on the topic. Graham's essays are uniformly interesting, if occasionaly controversial, and made it sense to check out the book.
Painters and Hackers is essentially a collection of relatively standalone essays that, taken together, represent Graham's view of what being a hacker is. That view is closely tied to his views on startups, and I guess, the philosophy behind ycombinator. Much of what Graham says is now convetional wisdom in the world of technology. Yet therein lies the lies the problem with the book. The book is about hackers who want to become entrepreneurs. While there may be a significant subset of hackers who do, by and large, most of the hackers I know, don't. More dangerously, conflating hackers with entrepreneurs is dangerous, for both the hacker and the entrepreneur. While both are in some sense non-confirmists, they are non-confirmists in very different ways.
Hackers solve problems that are interesting to them. Enterepreneurs make money. Making money, or creating wealth as Graham prefers to call it, although definitely an intersesting problem for many people is not usually, or even frequently, the sole motivation for a hacker to work on a problem. Graham sometimes forgets that.
Graham starts off somewhat autobiographically, describing his experience of being a nerd in high school. Some of his observations seemed very spot on — particularly those about how bad schools are at actually imparting any eduction. Having taught programming this past year, I have to concur with his observations in this area, although he may have missed out some other critical reasons why schools do such a bad job of educating children. But then again, the book was not intended to be encyclopediac on the subject.
A major assumption that Graham makes that has now become a trope in the startup world — that large companies are slow and small startups are faster. The problem with this assumption is that it is only true in some cases. It is important, and critically so for an entrepreneur to understand when this is true. Although, these conditions are outlined in the book, they are lost in the repeated and casual assertion that small companies are by their very nature faster. No they are not. For an example look at any small business in your neighborhood. Speed only comes with a concentration talent and purpose. Whether that concentration happens in a large or small company is less material.
Many of Graham's later essays in the book seem to be paens to capitalism. Gordon Gecko, meet Paul Graham. The irony is that while he argues for iconoclastic views of hackers, he is at the same time the ultimate supporter of the establishment. He has to be. He's one of them. As is normal with most of these discussions of wealth, he conveniently ignores that the deck is stacked against most people, even in the US. However, he is genrally right that technology has made the world as a whole materially wealthier, even if it has simultaneously made some people extraordinarily rich.
Graham makes a somewhat odd digression into techniques for fighting spam. The chapter doesn't really fit into the book, except perhaps as way of illustrating the sort of problem a hacker would attack. However, his prediction on the future of spam was spot on. Indeed spam in 2015 looks remarkably like his description of it. Unfortunately, that hasn't made Inboxes any more effective in 2015. The unwanted mail in my inbox comes mostly from LinkedIn, Google, Microsoft, Network Solutions and Github — the companies I pay for services.
Chapter 9 of the book describes the attributes of good design and many of Graham's observations are correct, if not original. Unfortunately though, as is the case with most advice on taste especially taste in design, it isn't actionable. There is good taste in design and there is bad taste in design bad design and most people can distingush between the two after the fact, but it is impossible to good job teaching how to acquire that taste in the first place. Experience perhaps helps but doesn't guarentee it.
Graham spends the second half of the book on the merits of various programming languages, ending with his now well known love-fest with Lisp. I'm not a Lisp expert, so I cannot say for sure how great a language it is, but I am sure that one programming language will still be used a hundred years after it was invented: C. It's already 40% of the way there! However, Graham's exhortations on behalf of Lisp did motivate me to crack open my copy of SICP.
Graham's example on writing an accumulator in various languages is good read for programmer though and I found the techniques worth examining, particularly for Python. I think Python has adopted lambdas now, so it has nearly the same power as the Lisp original.
Overall Hackers and Painters can be read as two distinct books: one that deals with entrepreneurship for programmers, and the other on programming language design. Both are interesting in their own right, but taken has whole they don't talk about much about either hacking or painting except in passing. And perhaps that's what the book is about. Hacking is such a diverse activity, that any coherent description of it might not be feasible.