Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

When those far removed from the creation of wealth — undergraduates, reporters, politicians — hear that the richest 5% of the people have half the total wealth, they tend to think injustice! An experienced programmer would be more likely to think is that all? The top 5% of programmers probably write 99% of the good software.

Salesmen are an exception. It’s easy to measure how much revenue they generate, and they’re usually paid a percentage of it.

A startup is not merely ten people, but ten people like you.

Like guerillas, startups prefer the difficult terrain of the mountains, where the troops of the central government can’t follow.

And you had better have a convincing explanation of why your technology would be hard to duplicate. Otherwise as soon as some big company becomes aware of it, they’ll make their own, and with their brand name, capital, and distribution clout, they’ll take away your market overnight. You’d be like guerillas caught in the open field by regular army forces.

Start by picking a hard problem, and then at every decision point, take the harder choice.

We would have much preferred a 100% chance of $1 million to a 20% chance of $10 million, even though theoretically the second is worth twice as much. Unfortunately, there is not currently any space in the business world where you can get the first deal.

I think it’s a good idea to get bought, if you can. Running a business is different from growing one.

What would you think of a financial advisor who put all his client’s assets into one volatile stock?

So I think you should make users the test, just as acquirers do. Treat a startup as an optimization problem in which performance is measured by number of users.

Until a few centuries ago, the main sources of wealth were mines, slaves and serfs, land, and cattle, and the only ways to acquire these rapidly were by inheritance, marriage, conquest, or confiscation. Naturally wealth had a bad reputation.

For most of the world’s history, if you did somehow accumulate a fortune, the ruler or his henchmen would find a way to steal it.

Since it became possible to get rich by creating wealth, everyone who has done it has used essentially the same recipe: measurement and leverage, where measurement comes from working with a small group, and leverage from developing new techniques. The recipe was the same in Florence in 1200 as it is in Santa Clara today.

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.

Money is just a convenient way of trading one form of wealth for another. Wealth is the underlying stuff — the goods and services we buy.

But I have no trouble imagining that one person could be 100 times as productive as another.

The only thing technology can’t cheapen is brand. Which is precisely why we hear ever more about it.

Now even the poorest Americans drive cars, and it is only because we’re so well trained by advertising that we can even recognize the especially expensive ones.

I’d like to propose an alternative idea: that in a modern society, increasing variation in income is a sign of health.

“A lot of them seem smart,” he said. “What I can’t tell is whether they have any kind of taste.”

GOOD DESIGN IS SIMPLE. You hear this from math to painting.

GOOD DESIGN IS TIMELESS. In math, every proof is timeless unless it contains a mistake.

if something is ugly, it can’t be the best solution. There must be a better one, and eventually someone else will discover it.

GOOD DESIGN SOLVES THE RIGHT PROBLEM.

GOOD DESIGN IS SUGGESTIVE.

GOOD DESIGN IS OFTEN SLIGHTLY FUNNY.

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

When you get to build your programs out of bigger concepts, you don’t need to use as many of them.

Lisp hackers already know about the value of being flexible with data structures. We tend to write the first version of a program so that it does everything with lists.

What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort. At least, that’s how we’d describe it in present-day terms.

an unimaginably inefficient implementation meeting unimaginably great resources.

Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches.

Except in special kinds of applications, parallelism won’t pervade the programs that are written in a hundred years. It would be premature optimization if it did.

The extreme case is probably literature; people studying literature rarely say anything that would be of the slightest use to those producing it.

In a big company, you can do what all the other big companies are doing. But a startup can’t do what all the other startups do. I don’t think a lot of people realize this, even in startups.

The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.

Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available. And the reason everyone doesn’t use it is that programming languages are not merely technologies, but habits of mind as well, and nothing changes slower.

Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it’s read by the parser, is made of data structures that you can traverse.

Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp.

If you ever do find yourself working for a startup, here’s a handy tip for evaluating competitors. Read their job listings. Everything else on their site may be stock photos or the prose equivalent, but the job listings have to be specific about what they want, or they’ll get the wrong candidates.

The first thing I would do, after checking to see if they had a live online demo, was look at their job listings.

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

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

What he’s thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won’t get in trouble for using it. And that also means there will always be lots of Java programmers, so if those working for me now quit, as programmers working for me mysteriously always do, I can easily replace them. Well, this doesn’t sound that unreasonable. But it’s all based on one unspoken assumption, and that assumption turns out to be false. The pointy-haired boss believes that all programming languages are pretty much equivalent.

So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale. The right thing to compare Lisp to is not 1950s hardware but the Quick sort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.

I can think of three problems that could arise from using less common languages. Your programs might not work well with programs written in other languages. You might have fewer libraries at your disposal. And you might have trouble hiring programmers.

In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language, you probably won’t need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter.

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.

Because, 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. Within large organizations, the phrase used to describe this approach is “industry best practice.”

Given that you can supply the three things any language needs — a free implementation, a book, and something to hack — how do you make a language that hackers will like? One thing hackers like is succinctness.