Paul Graham on hackers

I was reading Paul Graham's essay entitled Great Hackers this morning. He seems to have clearly and concisely enunciated several opinions that are common among techy people, although he is somewhat extreme in his views:

Great programmers are sometimes said to be indifferent to money. This isn't quite true. It is true that all they really care about is doing interesting work. But if you make enough money, you get to work on whatever you want, and for that reason hackers are attracted by the idea of making really large amounts of money. But as long as they still have to show up for work every day, they care more about what they do there than how much they get paid for it.

I'm not sure that this is entirely true; it seems to assume no other especially interesting and/or time-consuming hobbies. A really good programmer might make a pile of money and decide to quit her job completely, because what she really wants is to only program when she wants, on things she's interested in, and no job can guarantee that all the time. Instead she gets a pilot's license and travels around the world for a couple of years. Of course, she would have to bring along her laptop.

A great programmer might be ten or a hundred times as productive as an ordinary one, but he'll consider himself lucky to get paid three times as much.

This is a fact that often seems to be completely ignored by management. All programmers are not created equal. It's not even that the best programmer is twice as good as the worst programmer. The worst programmer should actually count as a negative when it comes to calculating man-months (which are mythical anyway, as we all know), since he probably makes mistakes that waste everyone else's time. No, the best programmer is certainly orders of magnitude better than even the average programmer, and should be valued accordingly. I say this as an about average programmer, myself.

Here's another interesting quote:

When you decide what infrastructure to use for a project, you're not just making a technical decision. You're also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python.

[...]

Business types prefer the most popular languages because they view languages as standards. They don't want to bet the company on Betamax. The thing about languages, though, is that they're not just standards. If you have to move bits over a network, by all means use TCP/IP. But a programming language isn't just a format. A programming language is a medium of expression.

This is a very good point. I code primarily in Java nowadays, and Java is awesome in that it takes care of a lot of details for me and prevents bugs like memory leaks, but it makes me lazy. I think ideally companies should hire programmers that are skilled in multiple languages, and give them the freedom to choose from a (small) set of languages when starting on new projects. Different types of projects call for different implementation languages.

His thoughts on office space are dead-on:

After software, the most important tool to a hacker is probably his office. Big companies think the function of office space is to express rank. But hackers use their offices for more than that: they use their office as a place to think in. And if you're a technology company, their thoughts are your product. So making hackers work in a noisy, distracting environment is like having a paint factory where the air is full of soot.

The cartoon strip Dilbert has a lot to say about cubicles, and with good reason. All the hackers I know despise them. The mere prospect of being interrupted is enough to prevent hackers from working on hard problems. If you want to get real work done in an office with cubicles, you have two options: work at home, or come in early or late or on a weekend, when no one else is there. Don't companies realize this is a sign that something is broken? An office environment is supposed to be something you work in, not something you work despite.

Regardless of the reason, whether it's productivity or something else, engineers usually demonstrate a clear preference for offices. We had a engineering satisfaction survey at work earlier this year, which posed the following question, "Given the exact same space (same size, desk area, window access, etc.), I would prefer to work in a... (a) Cube (b) Office (c) Don't care (d) Other." 70% of respondents answered (b) Office, 8% answered (a) Cube, and 17% answered (c) Don't care.

On managing engineers:

Hackers like to work for people with high standards. But it's not enough just to be exacting. You have to insist on the right things. Which usually means that you have to be a hacker yourself. I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you're not. And the second could probably be condensed into two words: give up.

The problem is not so much the day to day management. Really good hackers are practically self-managing. The problem is, if you're not a hacker, you can't tell who the good hackers are. A similar problem explains why American cars are so ugly. I call it the design paradox. You might think that you could make your products beautiful just by hiring a great designer to design them. But if you yourself don't have good taste, how are you going to recognize a good designer? By definition you can't tell from his portfolio. And you can't go by the awards he's won or the jobs he's had, because in design, as in most fields, those tend to be driven by fashion and schmoozing, with actual ability a distant third. There's no way around it: you can't manage a process intended to produce beautiful things without knowing what beautiful is. American cars are ugly because American car companies are run by people with bad taste.

Many people in this country think of taste as something elusive, or even frivolous. It is neither. To drive design, a manager must be the most demanding user of a company's products. And if you have really good taste, you can, as Steve Jobs does, make satisfying you the kind of problem that good people like to work on.

Lastly, here's a quote about talented people in general:

Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.

This rings true; what appears as false modesty to others is probably just ignorance. After all, if you consider yourself the norm, why shouldn't everyone else be just as smart or fast or talented as you?

Anyway, I'm glad I took the time to read through the whole essay. Graham's ideas are original and quite discussion-worthy, and more impressively (for a technical person), they are presented in vivid and well written detail. Go read it!