Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.

If you work for a big company, this may not be easy. You will have a hard time convincing the pointy-haired boss to let you build things in Lisp, when he has just read in the paper that some other language is poised, like Ada was twenty years ago, to take over the world. But if you work for a startup that doesn’t have pointy haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.

If you look at these languages in order, Java, Perl, Python, Ruby, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp.

You can’t let the suits make technical decisions for you. Did it alarm potential acquirers that we used Lisp? Some, slightly, but if we hadn’t used Lisp, we wouldn’t have been able to write the software that made them want to buy us. What seemed like an anomaly to them was in fact cause and effect. If you start a startup, don’t design your product to please VCs or potential acquirers. Design your product to please the users. If you win the users, everything else will follow. And if you don’t, no one will care how comfortingly orthodox your technology choices were.

when it comes down to it, the pointy-haired boss doesn’t mind if his company gets their ass kicked, so long as no one can prove it’s his fault. The safest plan for him personally is to stick close to the center of the herd. Within large organizations, the phrase used to describe this approach is “industry best practice.” Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is “industry best practice,” and the company loses, he can’t be blamed. He didn’t choose, the industry did.

If you want to win in a software business, just take on the hardest problem you can find, use the most powerful language you can get, and wait for your competitors’ pointy-haired bosses to revert to the mean.

Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough — often that I’m generating by hand the expansions of some macro that I need to write.

Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. — C.S.LEWIS

A language also needs to have a book about it. The book should be thin, well-written, and full of good examples. Kernighan and Ritchie’s C Programming Language is the ideal here. At the moment I’d almost say that a language has to have a book published by O’Reilly. That’s becoming the test of mattering to hackers.

Hackers like to hack, and hacking means getting inside things and second-guessing the original designer. Let yourself be second-guessed. When you make any tool, people use it in ways you didn’t intend, and this is especially true of a highly articulated tool like a programming language.

Another way to get a big program is to start with a throwaway program and keep improving it. This approach is less daunting, and the design of the program benefits from evolution.

Maybe this is how u build enduring things. Evolution. Not from grand design

Inventors of wonderful new things are often surprised to discover this, but you need time to get any message through to people. A friend of mine rarely does anything the first time someone asks him. He knows that people sometimes ask for things they turn out not to want. To avoid wasting his time, he waits till the third or fourth time he’s asked to do something. By then whoever’s asking him may be fairly annoyed, but at least they probably really do want whatever they’re asking for.

Most people have learned to do a similar sort of filtering on new things they hear about. They don’t even start paying attention until they’ve heard about something ten times. They’re perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all.

So anyone who invents something new has to expect to keep repeating their message for years before people will start to get it. It took us years to get it through to people that Viaweb’s software didn’t have to be downloaded. The good news is, simple repetition solves the problem. All you have to do is keep telling your story, and eventually people will start to hear. It’s not...

To write good software you must simultaneously keep two opposing ideas in your head. You need the young hacker’s naive faith in his abilities, and at the same time the veteran’s skepticism. You have to be able to think how hard can it be? with one half of your brain while thinking it will never work with the other.

The trick is to realize that there’s no real contradiction here. You want to be optimistic and skeptical about two different things. You have to be optimistic about the possibility of solving the problem, but skeptical about the value of whatever solution you’ve got so far.

People who do good work often think that whatever they’re working on is no good. Others see what they’ve done and think it’s wonderful, but the creator sees nothing but flaws. This pa...

Also, as a general rule, you can at any given time get away with changing more than you think. Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it.

Design begins by asking, who is this for and what do they need from it? A good architect, for example, does not begin by creating a design that he then imposes on the users, but by studying the intended users and figuring out what they need. Notice I said “what they need,” not “what they want.” I don’t mean to give the impression that working as a designer means working as a sort of short-order cook, making whatever the client tells you to. This varies from field to field in the arts, but I don’t think there is any field in which the best work is done by the people who just make exactly what the customers tell them to.

And yet, making what works for the user doesn’t mean simply making what the user tells you to. Users don’t know what all the choices are, and are often mistaken about what they really want. It’s like being a doctor. You can’t just treat a patient’s symptoms. When a patient tells you his symptoms, you have to figure out what’s actually wrong with him, and treat that.

You’re most likely to get good design if the intended users include the designer himself. When you design something for a group that doesn’t include you, it tends to be for people you consider less sophisticated than you, not more sophisticated. And looking down on the user, however benevolently, always seems to corrupt the designer.

If you think you’re designing something for idiots, odds are you’re not designing something good, even for idiots.

To get good design you have to get close, and stay close, to your users. You have to calibrate your ideas on actual users constantly. One of the reasons Jane Austen’s novels are so good is that she read them out loud to her family. That’s why she never sinks into self-indulgently arty descriptions of landscapes, or pretentious philosophizing.

Morale is key in design. I’m surprised people don’t talk more about it. One of my first drawing teachers told me: if you’re bored when you’re drawing something, the drawing will look boring.