Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

“no art, however minor, demands less than total dedication if you want to excel in it.”1

Another reason kids persecute nerds is to make themselves feel better. When you tread water, you lift yourself up by pushing water down. Likewise, in any social hierarchy, people unsure of their own position will try to emphasize it by maltreating those they think rank below. I’ve read that this is why poor whites in the United States are the group most hostile to blacks.

Humans like to work; in most of the world, your work is your identity.

In almost any group of people you’ll find hierarchy. When groups of adults form in the real world, it’s generally for some common purpose, and the leaders end up being those who are best at it. The problem with most schools is, they have no purpose. But hierarchy there must be. And so the kids make one out of nothing.

Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they’re doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers — studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters.

Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it’s there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.

hacking can certainly be more than just deciding how to implement some spec. At its best, it’s creating the spec — though it turns out the best way to do that is to implement it.

The way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way.

All the time I was in graduate school I had an uncomfortable feeling in the back of my mind that I ought to know more theory, and that it was very remiss of me to have forgotten all that stuff within three weeks of the final exam. Now I realize I was mistaken. Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry. You need to know how to calculate time and space complexity, and perhaps also the concept of a state machine, in case you want to write a parser.

You should figure out programs as you’re writing them, just as writers and painters and architects do.

Everyone in the sciences secretly believes that mathematicians are smarter than they are.

Writers do this too. Benjamin Franklin learned to write by summarizing the points in the essays of Addison and Steele and then trying to reproduce them. Raymond Chandler did the same thing with detective stories.

Everyone by now presumably knows about the danger of premature optimization. I think we should be just as worried about premature design — deciding too early what a program should do.

Relentlessness wins because, in the aggregate, unseen details become visible.

Empathy is probably the single most important difference between a good hacker and a great one.

Programs should be written for people to read, and only incidentally for machines to execute.

if they have time machines in the future they’ll probably have a separate reference manual just for Cambridge. This has always been a fussy place, a town of i dotters and t crossers, where you’re liable to get both your grammar and your ideas corrected in the same conversation.

Kids’ heads are repositories of all our taboos. It seems fitting to us that kids’ ideas should be bright and clean. The picture we give them of the world is not merely simplified, to suit their developing minds, but sanitized as well, to suit our ideas of what kids should think.6

When you find something you can’t say, what do you do with it? My advice is, don’t say it. Or at least, pick your battles.

Argue with idiots, and you become an idiot.

The people you can say heretical things to without getting jumped on are also the most interesting to know.

Ask anyone, and they’ll say the same thing: they’re pretty open-minded, though they draw the line at things that are really wrong.

Those in a position to impose rules naturally want them to be obeyed.

This way of writing software is a double-edged sword of course. It works a lot better for a small team of good, trusted programmers than it would for a big company of mediocre ones, where bad ideas are caught by committees instead of the people who had them.

Desktop software forces users to become system administrators. Web-based software forces programmers to. There is less stress in total, but more for the programmers.

Web pages weren’t designed to be a UI for applications, but they’re just good enough. And for a significant number of users, software you can use from any browser will be enough of a win in itself to outweigh any awkwardness in the UI.

There are only two things you have to know about business: build something users love, and make more than you spend. If you get these two right, you’ll be ahead of most startups. You can figure out the rest as you go.

As for building something users love, here are some general tips. Start by making something clean and simple that you would want to use yourself. Get a version 1.0 out fast, then continue to improve the software, listening closely to users as you do. The customer is always right, but different customers are right about different things; the least sophisticated users show you what you need to simplify and clarify, and the most sophisticated tell you what features you need to add. The best thing software can be is easy, but the way to do this is to get the defaults right, not to limit users’ choices. Don’t get complacent if your competitors’ software is lame; the standard to compare your software to is what it could be, not what your current competitors happen to have. Use your software yourself, all the time.

Money is a side effect of specialization. In a specialized society, most of the things you need, you can’t make for yourself. If you want a potato or a pencil or a place to live, you have to get it from someone else.

In the right kind of business, someone who really devoted himself to work could generate ten or even a hundred times as much wealth as an average employee. A programmer, for example, instead of chugging along maintaining and updating an existing piece of software, could write a whole new piece of software, and with it create a new source of revenue. Companies are not set up to reward people who want to do this. You can’t go to your boss and say, I’d like to start working ten times as hard, so will you please pay me ten times as much? For one thing, the official fiction is that you are already working as hard as you can. But a more serious problem is that the company has no way of measuring the value of your work.

So all other things being equal, a very able person in a big company is probably getting a bad deal, because his performance is dragged down by the overall lower performance of the others. Of course, all other things often are not equal: the able person may not care about money, or may prefer the stability of a large company. But a very able person who does care about money will ordinarily do better to go off and work with a small group of peers.

It’s common for a startup to be developing a genuinely good product, take slightly too long to do it, run out of money, and have to shut down.

why Europe grew so powerful. Was it something about the geography of Europe? Was it that Europeans are somehow racially superior? Was it their religion? The answer (or at least the proximate cause) may be that the Europeans rode on the crest of a powerful new idea: allowing those who made a lot of money to keep it.

But since for most of the world’s history the main route to wealth was to steal it, we tend to be suspicious of rich people. Idealistic undergraduates find their unconsciously preserved child’s model of wealth confirmed by eminent writers of the past. It is a case of the mistaken meeting the outdated.

If I had a choice of living in a society where I was materially much better off than I am now, but was among the poorest, or in one where I was the richest, but much worse off than I am now, I’d take the first option. If I had children, it would arguably be immoral not to. It’s absolute poverty you want to avoid, not relative poverty. If, as the evidence so far implies, you have to have one or the other in your society, take relative poverty.

If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.

GOOD DESIGN IS SIMPLE. You hear this from math to painting. In math it means that a shorter proof tends to be a better one. Where axioms are concerned, especially, less is more. It means much the same thing in programming. For architects and designers, it means that beauty should depend on a few carefully chosen structural elements rather than a profusion of superficial ornament. (Ornament is not in itself bad, only when it’s camouflage on insipid form.) Similarly, in painting, a still life of a few carefully observed and solidly modelled objects will tend to be more interesting than a stretch of flashy but mindlessly repetitive painting of, say, a lace collar. In writing it means: say what you mean and say it briefly.

Mistakes are natural. Instead of treating them as disasters, make them easy to acknowledge and easy to fix. Leonardo more or less invented the sketch, as a way to make drawing bear a greater weight of exploration. Open source software has fewer bugs because it admits the possibility of bugs.

The more you have to say to get something done, the harder it is to see bugs.

It’s like the rule that in buying a house you should consider location first of all. Everything else you can fix later, but you can’t fix the location.

I’m like someone who grew up poor and can’t bear to spend money even for something important, like going to the doctor.

In the software business there is an ongoing struggle between the pointy-headed academics, and another equally formidable force, the pointy-haired bosses.

you know, 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.

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 pattern is no coincidence: worry made the work good.

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

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.”