Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

Computers have had far more effect on the form of our lives than space travel or nuclear technology.

Good hackers develop a habit of questioning everything.

When the things you do have real effects, it’s no longer enough just to be pleasing. It starts to be important to get the right answers, and that’s where nerds show to advantage.

Officially the purpose of schools is to teach kids. In fact their primary purpose is to keep kids locked up in one place for a big chunk of the day so adults can get things done.

We have a phrase to describe what happens when rankings have to be created without any meaningful criteria. We say that the situation degenerates into a popularity contest.

The real problem is the emptiness of school life. We won’t see solutions till adults realize that.

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. This kind of work is hard to convey in a research paper.

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.

As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.

Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.

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

It’s a good idea to save some easy tasks for moments when you would otherwise stall.

The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner, and with interfaces between them that are as carefully designed and, if possible, as articulated as programming languages.

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.

The statements that make people mad are the ones they worry might be believed. I suspect the statements that make people maddest are those they worry might be true.

To find them, keep track of opinions that get people in trouble, and start asking, could this be true? Ok, it may be heretical (or whatever modern equivalent), but might it also be true?

When a politician says his opponent is mistaken, that’s a straightforward criticism, but when he attacks a statement as “divisive” or “racially insensitive” instead of arguing that it’s false, we should start paying attention.

Whatever the reason, there seems a clear correlation between intelligence and willingness to consider shocking ideas.

Training yourself to think unthinkable thoughts has advantages beyond the thoughts themselves. It’s like stretching. When you stretch before running, you put your body into positions much more extreme than any it will assume during the run. If you can think things so outside the box that they’d make people’s hair stand on end, you’ll have no trouble with the small trips outside the box that people call innovative.

Argue with idiots, and you become an idiot. The most important thing is to be able to think what you want, not to say what you want.

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

You don’t need to say that it’s heretical. And if it isn’t false, it shouldn’t be suppressed. So when you see statements being attacked as x-ist or y-ic (substitute your current values of x and y), whether in 1630 or 2030, that’s a sure sign that something is wrong. When you hear such labels being used, ask why.

Always be questioning. That’s the only defence. What can’t you say? And why?

With server-based software, most of the change is small and incremental. That in itself is less likely to introduce bugs.

Software companies are sometimes accused of letting the users debug their software. And that is just what I’m advocating.

Our policy of fixing bugs on the fly changed the relationship between customer support people and hackers.

At most software companies, support people are underpaid human shields, and hackers are little copies of God the Father, creators of the world.

Within a minute of hearing about a bug from a customer, the support people could be standing next to a programmer hearing him say “Shit, you’re right, it’s a bug.”

Have you ever noticed that when you sit down to write something, half the ideas that end up in it are ones you thought of while writing? The same thing happens with software.

Working to implement one idea gives you more ideas. So shelving an idea costs you not only that delay in implementing it, but also all the ideas that implementing it would have led to.

Plans are just another word for ideas on the shelf. When we thought of good ideas, we implemented them.

When you can write software with fewer programmers, it saves you more than money. As Fred Brooks pointed out in The Mythical Man-Month, adding people to a project tends to slow it down.

Fortunately, this process also works in reverse: as groups get smaller, software development gets exponentially more efficient.

If you give up direct control of the servers, you give up most of the advantages of developing web-based applications.

If a company wants to make a platform that startups will build on, they have to make it something that hackers themselves will want to use.

Web-based applications are cheap to develop, and easy for even the smallest startup to deliver. They’re a lot of work, and of a particularly stressful kind, but that only makes the odds better for startups.

There are only two things you have to know about business: build something users love, and make more than you spend.

software has to be designed by hackers who understand design, not designers who know a little about software.

If you can’t design software as well as implement it, don’t start a startup.

If you wanted to get rich, how would you do it? I think your best bet would be to start or join a startup.

A startup is a small company that takes on a hard technical problem.

There is a large random factor in the success of any company.

If you want to create wealth, it will help to understand what it is. Wealth is not the same thing as money.3 Wealth is as old as human history. Far older, in fact; ants have wealth. Money is a comparatively recent invention.

A programmer can sit down in front of a computer and create wealth. A good piece of software is, in itself, a valuable thing. There is no manufacturing to confuse the issue. Those characters you type are a complete, finished product. If someone sat down and wrote a web browser that didn’t suck (a fine idea, by the way), the world would be that much richer.

The top 5% of programmers probably write 99% of the good software.

All a company is is a group of people working together to do something people want. It’s doing something people want that matters, not joining the group.

To get rich you need to get yourself in a situation with two things, measurement and leverage. You need to be in a position where your performance can be measured, or there is no way to get paid more by doing more. And you have to have leverage, in the sense that the decisions you make have a big effect.

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

Steve Jobs once said that the success or failure of a startup depends on the first ten employees. I agree. If anything, it’s more like the first five.