Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

The kind of language designers who like to think about how to design type systems may shudder at this. It’s almost like writing applications! Well, too bad. Languages are for programmers, and libraries are what programmers need.

And Parkinson’s Law has proven as powerful as Moore’s. Software has bloated to consume the resources available.

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.

Organic growth seems to yield better technology and richer founders than the big bang method. If you look at the dominant technologies today, you’ll find that most of them grew organically.

“The best writing is rewriting,” wrote E. B. White. Every good writer knows this, and it’s true for software too.

The most important part of design is redesign. Programming languages, especially, don’t get redesigned enough.

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.

It’s tricky to keep the two forces balanced. In young hackers, optimism predominates. They produce something, are convinced it’s great, and never improve it. In old hackers, skepticism predominates, and they won’t even dare to take on ambitious projects.

Anything you can do to keep the redesign cycle going is good.

Prose can be rewritten over and over until you’re happy with it. But software, as a rule, doe...

By way of summary, let’s try describing the hacker’s dream language. The dream language is clean and terse. It has an interactive top level that starts up fast. You can write programs to solve common problems with very little code.

The dream language is not only open source, but open design.

I don’t think you can even talk about good or bad design except with reference to some intended user.

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.

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

You may dispute either of the premises, but if a language has to have a toplevel to be convenient, and mandatory type declarations are incompatible with a toplevel, then no language that makes type declarations mandatory could be convenient to program in.

To get good design you have to get close, and stay close, to your users.

You can do this in software too. A prototype doesn’t have to be just a model; you can refine it into the finished product. I think you should always do this when you can. It lets you take advantage of new insights you have along the way. But perhaps even more important, it’s good for morale.

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.

Building something by gradually refining a prototype is good for morale because it keeps you engaged. In software, my rule is: always have working code. If you’re writing something you’ll be able to test in an hour, you have the prospect of an immediate reward to motivate you.

“A painting is never finished. You just stop working on it.” This idea will be familiar to anyone who has worked on software.

Morale is another reason that it’s hard to design something for an unsophisticated user. It’s hard to stay interested in something you don’t like yourself. To make something good, you have to be thinking, “wow, this is really great,” not “what a piece of shit; those fools will love it.”

Design means making things for humans. But it’s not just the user who’s human. Th...