Tarang's Book Highlights

Hackers & Painters: Big Ideas From the Computer Age

Paul Graham

Preface

Though hackers generally look dull on the outside, the insides of their heads are surprisingly interesting places.

| Location: 190 | Color: yellow |



1. Why Nerds Are Unpopular

Chapter 1. Why Nerds Are Unpopular

Notes:

7/10

| Location: 192 | Color: yellow |

So if intelligence in itself is not a factor in popularity, why are smart kids so consistently unpopular? The answer, I think, is that they don’t really want to be popular. If someone had told me that at the time, I would have laughed at him. Being unpopular in school makes kids miserable, some of them so miserable that they commit suicide. Telling me that I didn’t want to be popular would have seemed like telling someone dying of thirst in a desert that he didn’t want a glass of water. Of course I wanted to be popular. But in fact I didn’t, not enough. There was something else I wanted more: to be smart. Not simply to do well in school, though that counted for something, but to design beautiful rockets, or to write well, or to understand how to program computers. In general, to make great things. At the time I never tried to separate my wants and weigh them against one another. If I had, I would have seen that being smart was more important. If someone had offered me the chance to be the most popular kid in school, but only at the price of being of average intelligence (humor me here), I wouldn’t have taken it.

| Location: 210 | Color: yellow |

Nerds serve two masters. They want to be popular, certainly, but they want even more to be smart. And popularity is not something you can do in your spare time, not in the fiercely competitive environment of an American secondary school.

| Location: 223 | Color: yellow |

The main reason nerds are unpopular is that they have other things to think about. Their attention is drawn to books or the natural world, not fashions and parties. They’re like someone trying to play soccer while balancing a glass of water on his head. Other players who can focus their whole attention on the game beat them effortlessly, and wonder why they seem so incapable.

| Location: 239 | Color: pink |

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. Bill Gates will of course come to mind. Though notoriously lacking in social skills, he gets the right answers, at least as measured in revenue. The other thing that’s different about the real world is that it’s much larger. In a large enough pool, even the smallest minorities can achieve a critical mass if they clump together. Out in the real world, nerds collect in certain places and form their own societies where intelligence is the most important thing.

| Location: 307 | Color: yellow |

Any immediate improvement in nerds’ lives is probably going to have to come from the nerds themselves. Merely understanding the situation they’re in should make it less painful. Nerds aren’t losers. They’re just playing a different game, and a game much closer to the one played in the real world. Adults know this. It’s hard to find successful adults now who don’t claim to have been nerds in high school.

| Location: 423 | Color: yellow |



2. Hackers and Painters

Chapter 2. Hackers and Painters

Notes:

7/10

| Location: 434 | Color: yellow |

I’ve never liked the term “computer science.” The main reason I don’t like it is that there’s no such thing. 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.

| Location: 442 | Color: yellow |

Sometimes what the hackers do is called “software engineering,” but this term is just as misleading. 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. What and how should not be kept too separate. You’re asking for trouble if you try to decide what to do without understanding how to do

| Location: 448 | Color: yellow |

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.

| Location: 451 | Color: yellow |

instead of doing what they really want to do, which is to design beautiful software, hackers in universities and research labs feel they ought to be writing research papers. In the best case, the papers are just a formality. Hackers write cool software, and then write a paper about it, and the paper becomes a proxy for the achievement represented by the software. But often this mismatch causes problems. It’s easy to drift away from building beautiful things toward building ugly things that make more suitable subjects for research papers.

| Location: 460 | Color: yellow |

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. So why do universities and research labs continue to judge hackers by publications? For the same reason that “scholastic aptitude” gets measured by simple-minded standardized tests, or the productivity of programmers by lines of code. These tests are easy to apply, and there is nothing so tempting as an easy test that kind of works. Measuring what hackers are actually trying to do, designing beautiful software, would be much more difficult.

| Location: 470 | Color: blue |

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. Painters have to remember a good deal more about paint chemistry than that.

| Location: 487 | Color: blue |

I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging. For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. 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. Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

| Location: 492 | Color: yellow |

Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code. This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it’s hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design. If you want to make money at some point, remember this, because this is one of the reasons startups win. 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. So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you. These opportunities are not easy to find, though. It’s hard to engage a big company in a design war, just as it’s hard to engage an opponent inside a castle in hand-to-hand combat.

| Location: 516 | Color: yellow |

The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That’s where you can win big by taking the bold approach to design, and having the same people both design and implement the product. Microsoft themselves did this at the start. So did Apple. And Hewlett- Packard. I suspect almost every successful startup has. So one way to build great software is to start your own startup.

| Location: 528 | Color: pink |

I think the answer to this problem, in the case of software, is a concept known to nearly all makers: the day job. This phrase began with musicians, who perform at night. More generally, it means you have one kind of work you do for money, and another for love. Nearly all makers have day jobs early in their careers. Painters and writers notoriously do. If you’re lucky you can get a day job closely related to your real work. Musicians often seem to work in record stores. A hacker working on some programming language or operating system might likewise be able to get a day job using it.2

| Location: 542 | Color: pink |

When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects of your own.3

| Location: 551 | Color: pink |

One thing we can learn, or at least confirm, from the example of painting is how to learn to hack. You learn to paint mostly by doing it. Ditto for hacking. Most hackers don’t learn to hack by taking college courses in programming. They learn by writing programs of their own at age thirteen. Even in college classes, you learn to hack mostly by hacking.4

| Location: 555 | Color: blue |

The fact that hackers learn to hack by doing it is another sign of how different hacking is from the sciences. Scientists don’t learn science by doing it, but by doing labs and problem sets. Scientists start out doing work that’s perfect, in the sense that they’re just trying to reproduce work someone else has already done for them. Eventually, they get to the point where they can do original work. Whereas hackers, from the start, are doing original work; it’s just very bad. So hackers start original, and get good, and scientists start good, and get original.

| Location: 564 | Color: blue |

Here’s a case where we can learn from painting. I think hacking should work this way too. It’s unrealistic to expect that the specifications for a program will be perfect. You’re better off if you admit this up front, and write programs in a way that allows specifications to change on the fly. (The structure of large companies makes this hard for them to do, so here is another place where startups have an advantage.) 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. The right tools can help us avoid this danger. A good programming language should, like oil paint, make it easy to change your mind. Dynamic typing is a win here because you don’t have to commit to specific data representations up front.

| Location: 579 | Color: blue |

The easiest program to change is one that’s short.

| Location: 586 | Color: blue |

If a hacker were a mere implementor, turning a spec into code, then he could just work his way through it from one end to the other like someone digging a ditch. But if the hacker is a creator, we have to take inspiration into account. In hacking, like painting, work comes in cycles. Sometimes you get excited about a new project and you want to work sixteen hours a day on it. Other times nothing seems interesting. To do good work you have to take these cycles into account, because they’re affected by how you react to them.

| Location: 598 | Color: blue |

Empathy is probably the single most important difference between a good hacker and a great one. Some hackers are quite smart, but practically solipsists when it comes to empathy. It’s hard for such people to design great software, because they can’t see things from the user’s point of view.6 One way to tell how good people are at empathy is to watch them explain a technical matter to someone without a technical background.

| Location: 628 | Color: blue |

Source code, too, should explain itself. If I could get people to remember just one quote about programming, it would be the one at the beginning of Structure and Interpretation of Computer Programs.8 Programs should be written for people to read, and only incidentally for machines to execute.

| Location: 639 | Color: blue |

You need to have empathy not just for your users, but for your readers. It’s in your interest, because you’ll be one of them. Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who’ve sworn off Perl after such experiences.9

| Location: 644 | Color: blue |



3.1. The Conformist Test

Mapmakers deliberately put slight mistakes in their maps so they can tell when someone copies them. If another map has the same mistake, that’s very convincing evidence.

| Location: 685 | Color: yellow |



3.4. Time and Space

We may imagine that we are a great deal smarter and more virtuous than past generations, but the more history you read, the less likely this seems.

| Location: 735 | Color: yellow |



3.6. Mechanism

So if you want to figure out what we can’t say, look at the machinery of fashion and try to predict what it would make un-sayable. What groups are powerful but nervous, and what ideas would they like to suppress? What ideas were tarnished by association when they ended up on the losing side of a recent struggle? If a self-consciously cool person wanted to differentiate himself from preceding fashions (e.g. from his parents), which of their ideas would he tend to reject? What are conventional-minded people afraid of saying? This technique won’t find us all the things we can’t say. I can think of some that aren’t the result of any recent struggle. Many of our taboos are rooted deep in the past. But this approach, combined with the preceding four, will turn up a good number of unthinkable ideas.

| Location: 801 | Color: yellow |



3.7. Why

Whatever the reason, there seems a clear correlation between intelligence and willingness to consider shocking ideas. This isn’t just because smart people actively work to find holes in conventional thinking. Conventions also have less hold over them to start with. You can see that in the way they dress. It’s not only in the sciences that heresy pays off. In any competitive field, you can win big by seeing things that others daren’t. And in every field there are probably heresies few dare utter.

| Location: 826 | Color: yellow |

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.

| Location: 834 | Color: pink |



3.8. Pensieri Stretti

Argue with idiots, and you become an idiot.

| Location: 843 | Color: blue |

The most important thing is to be able to think what you want, not to say what you want. And if you feel you have to say everything you think, it may inhibit you from thinking improper thoughts. I think it’s better to follow the opposite policy. Draw a sharp line between your thoughts and your speech. Inside your head, anything is allowed. Within my head I make a point of encouraging the most outrageous thoughts I can imagine. But, as in a secret society, nothing that happens within the building should be told to outsiders. The first rule of Fight Club is, you do not talk about Fight Club.

| Location: 844 | Color: yellow |



4. Good Bad Attitude

To the popular press, “hacker” means someone who breaks into computers. Among programmers it means a good programmer. But the two meanings are connected. To programmers, “hacker” connotes mastery in the most literal sense: someone who can make a computer do what he wants—whether the computer wants to or not. To add to the confusion, the noun “hack” also has two senses. It can be either a compliment or an insult. It’s called a hack when you do something in an ugly way. But when you do something so clever that you somehow beat the system, that’s also called a hack. The word is used more often in the former than the latter sense, probably because ugly solutions are more common than brilliant ones.

| Location: 915 | Color: yellow |

the two senses of “hack” are also connected. Ugly and imaginative solutions have something in common: they both break the rules. And there is a gradual continuum between rule breaking that’s merely ugly (using duct tape to attach something to your bike) and rule breaking that is brilliantly imaginative (discarding Euclidean space).

| Location: 920 | Color: yellow |

Hacking predates computers. When he was working on the Manhattan Project, Richard Feynman used to amuse himself by breaking into safes containing secret documents. This tradition continues today. When we were in grad school, a hacker friend of mine who spent too much time around MIT had his own lock picking kit.1

| Location: 923 | Color: blue |

It is sometimes hard to explain to authorities why one would want to do such things. Another friend of mine once got in trouble with the government for breaking into computers. This had only recently been declared a crime, and the FBI found that their usual investigative technique didn’t work. Police investigation apparently begins with a motive. The usual motives are few: drugs, money, sex, revenge. Intellectual curiosity was not one of the motives on the FBI’s list. Indeed, the whole concept seemed foreign to them.

| Location: 926 | Color: blue |

Those in authority tend to be annoyed by hackers’ general attitude of disobedience. But that disobedience is a byproduct of the qualities that make them good programmers. They may laugh at the CEO when he talks in generic corporate new speech, but they also laugh at someone who tells them a certain problem can’t be solved. Suppress one, and you suppress the other.

| Location: 930 | Color: yellow |

But even factoring in their annoying eccentricities, the disobedient attitude of hackers is a net win. I wish its advantages were better understood. For example, I suspect people in Hollywood are simply mystified by hackers’ attitudes toward copyrights. They are a perennial topic of heated discussion on Slashdot. But why should people who program computers be so concerned about copyrights, of all things? Partly because some companies use mechanisms to prevent copying. Show any hacker a lock and his first thought is how to pick it. But there is a deeper reason that hackers are alarmed by measures like copyrights and patents. They see increasingly aggressive measures to protect “intellectual property” as a threat to the intellectual freedom they need to do their job. And they are right. It is by poking about inside current technology that hackers get ideas for the next generation.

| Location: 935 | Color: yellow |

The next generation of computer technology has often—perhaps more often than not—been developed by outsiders. In 1977 there was no doubt some group within IBM developing what they expected to be the next generation of business computer. They were mistaken. The next generation of business computer was being developed on entirely different lines by two long-haired guys called Steve in a garage in Los Altos. At about the same time, the powers that be were cooperating to develop the official next generation operating system, Multics. But two guys who thought Multics excessively complex went off and wrote their own. They gave it a name that was a joking reference to Multics: Unix.

| Location: 942 | Color: yellow |



5.2. The Win for Users

With web-based applications, everyone uses the same version, and bugs can be fixed as soon as they’re discovered. So web-based software should have far fewer bugs than desktop software.

| Location: 1058 | Color: yellow |



5.3. City of Code

It did not end with software. We spent a lot of time thinking about server configurations. We built the servers ourselves, from components—partly to save money, and partly to get exactly what we wanted. We had to think about whether our upstream ISP had fast enough connections to all the backbones. We serially dated RAID suppliers. But hardware is not just something to worry about. When you control it you can do more for users. With a desktop application, you can specify certain minimum hardware, but you can’t add more.

| Location: 1087 | Color: yellow |



5.7. Morale

Being able to release software immediately is a big motivator. Often as I was walking to work I would think of some change I wanted to make to the software, and do it that day. This worked for bigger features as well. Even if something was going to take two weeks to write (few projects took longer), I knew I could see the effect in the software as soon as it was done. If I’d had to wait a year for the next release, I would have shelved most of these ideas,

| Location: 1195 | Color: yellow |

The thing about ideas, though, is that they lead to more ideas. 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. In fact, shelving an idea probably even inhibits new ideas: as you start to think of some new feature, you catch sight of the shelf and think, “but I already have a lot of new things I want to do for the next release.”

| Location: 1198 | Color: blue |

What big companies do instead of implementing features is plan them. At Viaweb we sometimes ran into trouble on this account. Investors and analysts would ask us what we had planned for the future. The truthful answer would have been, we didn’t have any plans. We had general ideas about things we wanted to improve, but if we knew how we would have done it already. What were we going to do in the next six months? Whatever looked like the biggest win. I don’t know if I ever dared give this answer, but that was the truth. Plans are just another word for ideas on the shelf. When we thought of good ideas, we implemented them.

| Location: 1203 | Color: yellow |

most code had one definite owner. But when you owned something you really owned it: no one except the owner of a piece of software had to approve (or even know about) a release. There was no protection against breakage except the fear of looking like an idiot to one’s peers, and that was more than enough. I may have given the impression that we just blithely plowed forward writing code. We did go fast, but we thought very carefully before we released software onto those servers. And paying attention is more important to reliability than moving slowly.

| Location: 1207 | Color: yellow |



5.10. Money

software development is an ongoing process. I think it’s cleaner if you openly charge subscription fees, instead of forcing people to keep buying and installing new versions so they’ll keep paying you. And fortunately, subscriptions are the natural way to bill for web-based applications.

| Location: 1268 | Color: yellow |



5.12. Son of Server

I don’t think many people realize how fragile and tentative startups are in the earliest stage. Many startups begin almost by accident—as a couple guys, either with day jobs or in school, writing a prototype of something that might, if it looks promising, turn into a company. At this larval stage, any significant obstacle will stop the startup dead in its tracks. Writing mainframe software required too much commitment up front.

| Location: 1338 | Color: yellow |

this was the beginning of a trend: desktop computers won because startups wrote software for them.

| Location: 1349 | Color: yellow |

There is all the more reason for startups to write web-based software now, because writing desktop software has become a lot less fun. If you want to write desktop software now, you do it on Microsoft’s terms, calling their APIs and working around their buggy OS. And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft.

| Location: 1359 | Color: yellow |

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. That means it has to be inexpensive and well-designed. The Mac was popular with hackers when it first came out, and a lot of them wrote software for it.14 You see this less with Windows, because hackers don’t use it. The kind of people who are good at writing software tend to be running Linux or FreeBSD now. I don’t think we would have started a startup to write desktop software, because desktop software has to run on Windows, and before we could write software for Windows we’d have to use it.

| Location: 1362 | Color: blue |



5.16. Why Not?

E. B. White was amused to learn from a farmer friend that many electrified fences don’t have any current running through them. The cows apparently learn to stay away from them, and after that you don’t need the current. “Rise up, cows!” he wrote. “Take your liberty while despots snore!” If you’re a hacker who has thought of one day starting a startup, there are probably two things keeping you from doing it. One is that you don’t know anything about business. The other is that you’re afraid of competition. Neither of these fences have any current in them. 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.

| Location: 1442 | Color: yellow |

You may not at first make more than you spend, but as long as the gap is closing fast enough you’ll be ok. If you start out under funded, it will at least encourage a habit of frugality. The less you spend, the easier it is to make more than you spend. Fortunately, it can be very cheap to launch a web-based application. We launched on under $10,000, and it would be even cheaper today.

| Location: 1449 | Color: blue |

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.

| Location: 1454 | Color: blue |

Don’t listen to marketing people or designers or product managers just because of their job titles. If they have good ideas, use them, but it’s up to you to decide; 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.

| Location: 1460 | Color: yellow |



6.1. The Proposition

Combine all these multipliers, and I’m claiming you could be 36 times more productive than you’re expected to be in a random corporate job.2 If a fairly good hacker is worth $80,000 a year at a big company, then a smart hacker working very hard without any corporate bullshit to slow him down should be able to do work worth about $3 million a year.

| Location: 1493 | Color: yellow |

Startups are not magic. They don’t change the laws of wealth creation. They just represent a point at the far end of the curve. There is a conservation law at work here: if you want to make a million dollars, you have to endure a million dollars’ worth of pain. For example, one way to make a million dollars would be to work for the Post Office your whole life, and save every penny of your salary. Imagine the stress of working for the Post Office for fifty years. In a startup you compress all this stress into three or four years. You do tend to get a certain bulk discount if you buy the economy-size pain, but you can’t evade the fundamental conservation law. If starting a startup were easy, everyone would do it.

| Location: 1500 | Color: blue |



6.3. Money Is Not Wealth

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. Wealth is the fundamental thing. Wealth is stuff we want: food, clothes, houses, cars, gadgets, travel to interesting places, and so on. You can have wealth without having money. If you had a magic machine that could on command make you a car or cook you dinner or do your laundry, or do anything else you wanted, you wouldn’t need money.

| Location: 1527 | Color: blue |

Wealth is what you want, not money.

| Location: 1533 | Color: pink |

The advantage of a medium of exchange is that it makes trade work. The disadvantage is that it tends to obscure what trade really means. People think that what a business does is make money. But money is just the intermediate stage—just a shorthand—for whatever people want. What most businesses really do is make wealth. They do something people want.4

| Location: 1544 | Color: blue |



6.4. The Pie Fallacy

Money is not wealth. It’s just something we use to move wealth around. So although there may be, in certain specific moments (like your family, this month) a fixed amount of money available to trade with other people for things you want, there is not a fixed amount of wealth in the world. You can make more wealth. Wealth has been getting created and destroyed (but on balance, created) for all of human history.

| Location: 1556 | Color: blue |



6.5. Craftsmen

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.

| Location: 1570 | Color: yellow |

A great programmer, on a roll, could create a million dollars worth of wealth in a couple weeks.

| Location: 1579 | Color: yellow |



6.6. What a Job Is

Nearly all companies exist to do something people want. And that’s what you do, as well, when you go to work for a company. But here there is another layer that tends to obscure the underlying reality. In a company, the work you do is averaged together with a lot of other people’s. You may not even be aware you’re doing something people want. Your contribution may be indirect. But the company as a whole must be giving people something they want, or they won’t make any money.

| Location: 1603 | Color: blue |

A more direct way to put it would be: you need to start doing something people want. You don’t need to join a company to do that. 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.6

| Location: 1610 | Color: blue |

A job means doing something people want, averaged together with everyone else in that company.

| Location: 1614 | Color: pink |



6.7. Working Harder

That averaging gets to be a problem. I think the single biggest problem afflicting large companies is the difficulty of assigning a value to each person’s work. For the most part they punt. In a big company you get paid a fairly predictable salary for working fairly hard. You’re expected not to be obviously incompetent or lazy, but you’re not expected to devote your whole life to your work. It turns out, though, that there are economies of scale in how much of your life you devote to your work. 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?

| Location: 1615 | Color: blue |

The top managers are held responsible for the performance of the entire company. Because an ordinary employee’s performance can’t usually be measured, he is not expected to do more than put in a solid effort. Whereas top management, like salespeople, have to actually come up with the numbers. The CEO of a company that tanks cannot plead that he put in a solid effort. If the company does badly, he’s done badly.

| Location: 1628 | Color: yellow |

If you want to go faster, it’s a problem to have your work tangled together with a large number of other people’s. In a large group, your performance is not separately measurable—and the rest of the group slows you down.

| Location: 1638 | Color: yellow |



6.8. Measurement and Leverage

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.

| Location: 1641 | Color: yellow |

I think every one who gets rich by their own efforts will be found to be in a situation with measurement and leverage. Everyone I can think of does: CEOs, movie stars, hedge fund managers, professional athletes. A good hint to the presence of leverage is the possibility of failure. Upside must be balanced by downside, so if there is big potential for gain there must also be a terrifying possibility of loss. CEOs, stars, fund managers, and athletes all live with the sword hanging over their heads; the moment they start to suck, they’re out. If you’re in a job that feels safe, you are not going to get rich, because if there is no danger there is almost certainly no leverage. But you don’t have to become a CEO or a movie star to be in a situation with measurement and leverage. All you need to do is be part of a small group working on a hard problem.

| Location: 1649 | Color: blue |



6.9. Smallness = Measurement

One level at which you can accurately measure the revenue generated by employees is at the level of the whole company. When the company is small, you are thereby fairly close to measuring the contributions of individual employees. A viable startup might only have ten employees, which puts you within a factor of ten of measuring individual effort. Starting or joining a startup is thus as close as most people can get to saying to one’s boss, I want to work ten times as hard, so please pay me ten times as much. There are two differences: you’re not saying it to your boss, but directly to the customers (for whom your boss is only a proxy after all), and you’re not doing it individually, but along with a small group of other ambitious people.

| Location: 1658 | Color: blue |

It’s a much better deal for them to average their work together with a small group of their peers than to average it with everyone. That’s the real point of startups. Ideally, you are getting together with a group of other people who also want to work a lot harder, and get paid a lot more, than they would in a big company. And because startups tend to get founded by self-selecting groups of ambitious people who already know one another (at least by reputation), the level of measurement is more precise than you get from smallness alone. 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. Being small is not, in itself, what makes startups kick butt, but rather that small groups can be select. You don’t want small in the sense of a village, but small in the sense of an all-star team.

| Location: 1673 | Color: blue |

The larger a group, the closer its average member will be to the average for the population as a whole. 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.

| Location: 1680 | Color: pink |



6.10. Technology = Leverage

Fortunately there is a natural fit between smallness and solving hard problems. The leading edge of technology moves fast. Technology that’s valuable today could be worthless in a couple years. Small companies are more at home in this world, because they don’t have layers of bureaucracy to slow them down. Also, technical advances tend to come from unorthodox approaches, and small companies are less constrained by convention. Big companies can develop technology. They just can’t do it quickly. Their size makes them slow and prevents them from rewarding employees for the extraordinary effort required. So in practice big companies only get to develop technology in fields where large capital requirements prevent startups from competing with them, like microprocessors, power plants, or passenger aircraft. And even in those fields they depend heavily on startups for components and ideas.

| Location: 1693 | Color: blue |

Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Via web one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.

| Location: 1704 | Color: blue |

What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we’d always take the harder one. Not just because it was more valuable, but because it was harder.

| Location: 1708 | Color: yellow |



6.11. The Catch(es)

If it were simply a matter of working harder than an ordinary employee and getting paid proportionately, it would obviously be a good deal to start a startup. Up to a point it would be more fun. I don’t think many people like the slow pace of big companies, the interminable meetings, the water-cooler conversations, the clueless middle managers, and so on. Unfortunately there are a couple catches. One is that you can’t choose the point on the curve that you want to inhabit. You can’t decide, for example, that you’d like to work just two or three times as hard, and get paid that much more. When you’re running a startup, your competitors decide how hard you work. And they pretty much all make the same decision: as hard as you possibly can.

| Location: 1728 | Color: yellow |

The other catch is that the payoff is only on average proportionate to your productivity. There is, as I said before, a large random multiplier in the success of any company. So in practice the deal is not that you’re 30 times as productive and get paid 30 times as much. It is that you’re 30 times as productive, and get paid between zero and a thousand times as much. If the mean is 30x, the median is probably zero. Most startups tank, and not just the dog food portals we all heard about during the Internet Bubble. 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.

| Location: 1733 | Color: blue |

Startups, like mosquitos, tend to be an all-or-nothing proposition. And you don’t generally know which of the two you’re going to get till the last minute. Via web came close to tanking several times. Our trajectory was like a sine wave. Fortunately we got bought at the top of the cycle, but it was damned close.

| Location: 1741 | Color: yellow |

The all-or-nothing aspect of startups was not something we wanted. Via web’s hackers were all extremely risk-averse. If there had been some way just to work super hard and get paid for it, without having a lottery mixed in, we would have been delighted. 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.

| Location: 1744 | Color: yellow |



6.12. Get Users

I think it’s a good idea to get bought, if you can. Running a business is different from growing one. It is just as well to let a big company take over once you reach cruising altitude. It’s also financially wiser, because selling allows you to diversify.

| Location: 1756 | Color: yellow |

How do you get bought? Mostly by doing the same things you’d do if you didn’t intend to sell the company. Being profitable, for example. But getting bought is also an art in its own right, and one that we spent a lot of time trying to master.

| Location: 1759 | Color: yellow |

For potential acquirers, the most powerful motivator is the prospect that one of their competitors will buy you. This, as we found, causes CEOs to take red-eyes. The second biggest is the worry that, if they don’t buy you now, you’ll continue to grow rapidly and will cost more to acquire later, or even become a competitor.

| Location: 1762 | Color: yellow |

You’d think that a company about to buy you would do a lot of research and decide for themselves how valuable your technology was. Not at all. What they go by is the number of users you have. In effect, acquirers assume the customers know who has the best technology. And this is not as stupid as it sounds. Users are the only real proof that you’ve created wealth. Wealth is what people want, and if people aren’t using your software, maybe it’s not just because you’re bad at marketing. Maybe it’s because you haven’t made what they want.

| Location: 1765 | Color: blue |

In a startup, you’re not just trying to solve problems. You’re trying to solve problems that users care about.

| Location: 1770 | Color: blue |

Among other things, treating a startup as an optimization problem will help you avoid another pitfall that VCs worry about, and rightly—taking a long time to develop a product. Now we can recognize this as something hackers already know to avoid: premature optimization. Get a version 1.0 out there as soon as you can. Until you have some users to measure, you’re optimizing based on guesses.

| Location: 1777 | Color: yellow |



6.13. Wealth and Power

Remember what a startup is, economically: a way of saying, I want to work faster. Instead of accumulating money slowly by being paid a regular wage for fifty years, I want to get it over with as soon as possible. So governments that forbid you to accumulate wealth are in effect decreeing that you work slowly. They’re willing to let you earn $3 million over fifty years, but they’re not willing to let you work so hard that you can do it in two. They are like the corporate boss that you can’t go to and say, I want to work ten times as hard, so please pay me ten times a much. Except this is not a boss you can escape by starting your own company.

| Location: 1798 | Color: yellow |



7.1. The Daddy Model of Wealth

In the real world, you can’t keep living off your parents. If you want something, you either have to make it, or do something of equivalent value for someone else, in order to get them to give you enough money to buy it. In the real world, wealth is (except for a few specialists like thieves and speculators) something you have to create, not something that’s distributed by Daddy.

| Location: 1848 | Color: yellow |



7.3. The Lever of Technology

Will technology increase the gap between rich and poor? It will certainly increase the gap between the productive and the unproductive. That’s the whole point of technology.

| Location: 1930 | Color: yellow |



9. Taste for Makers

Taste. You don’t hear that word much now. And yet we still need the underlying concept, whatever we call it. What my friend meant was that he wanted students who were not just good technicians, but who could use their technical knowledge to design beautiful things.

| Location: 2155 | Color: yellow |



12.1. The Secret Weapon

Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you’re starting a startup, you feel this keenly. Startups tend to be an all or nothing proposition. You either get rich, or you get nothing. In a startup, if you bet on the wrong technology, your competitors will crush you. Robert and I both knew Lisp well, and we couldn’t see any reason not to trust our instincts and use it. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn’t mean anything. If you chose technology that way, you’d be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work best.

| Location: 2702 | Color: blue |



12.3. Aikido for Startups

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.

| Location: 2846 | Color: blue |



13.4. Centripetal Forces

The third worry of the pointy-haired boss, the difficulty of hiring programmers, I think is a red herring. How many hackers do you need to hire, after all? Surely by now we all know that software is best developed by teams of less than ten people. And you shouldn’t have trouble hiring hackers on that scale for any language anyone has ever heard of. If you can’t find ten Lisp hackers, then your company is probably based in the wrong city for developing software. 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.

| Location: 3006 | Color: yellow |

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.

| Location: 3016 | Color: blue |



13.5. The Cost of Being Average

How much do you lose by using a less powerful language? There is actually some data out there about that. The most convenient measure of power is probably code size. The point of high-level languages is to give you bigger abstractions—bigger bricks, as it were, so you don’t need as many to build a wall of a given size. So the more powerful the language, the shorter the program (not simply in characters, of course, but in distinct elements).

| Location: 3021 | Color: blue |

Code size is important, because the time it takes to write a program depends mostly on its length. If your program would be three times as long in another language, it will take three times as long to write—and you can’t get around this by hiring more people, because beyond a certain size new hires are actually a net lose. Fred Brooks described this phenomenon in his famous book The Mythical Man-Month, and everything I’ve seen has tended to confirm what he said.

| Location: 3029 | Color: blue |



14.3. Succinctness

One thing hackers like is succinctness. Hackers are lazy, in the same way that mathematicians and modernist architects are lazy: they hate anything extraneous. It would not be far from the truth to say that a hacker about to write a program decides what language to use, at least subconsciously, based on the total number of characters he’ll have to type. If this isn’t precisely how hackers think, a language designer would do well to act as if it were.

| Location: 3187 | Color: yellow |

A hacker would consider being asked to write add x to y giving z instead of z = x + y as something between an insult to his intelligence and a sin against God. Succinctness is one place where statically typed languages lose. All other things being equal, no one wants to begin a program with a bunch of declarations. Anything that can be implicit, should be. The amount of boilerplate in a Java hello-world program is almost enough evidence, by itself, to convict.1

| Location: 3195 | Color: yellow |



14.4. Hackability

Good programmers often want to do dangerous and unsavory things. By unsavory I mean things that go behind whatever semantic facade the language is trying to present: getting hold of the internal representation of some high-level abstraction, for example. Hackers like to hack, and hacking means getting inside things and second-guessing the original designer.

| Location: 3211 | Color: yellow |

A really good language should be both clean and dirty: cleanly designed, with a small core of well understood and highly orthogonal operators, but dirty in the sense that it lets hackers have their way with it. C is like this.

| Location: 3221 | Color: yellow |



14.5. Throwaway Programs

To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs. A throwaway program is a program you write quickly for some limited task: a program to automate some system administration task, or generate test data for a simulation, or convert data from one format to another. The surprising thing about throwaway programs is that, like the “temporary” buildings built at so many American universities during World War II, they often don’t get thrown away. Many evolve into real programs, with real features and real users.

| Location: 3227 | Color: yellow |



14.10. The Dream Language

The Dream Language 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.3 You can write programs to solve common problems with very little code. Nearly all the code in any program you write is code that’s specific to your application. Everything else has been done for you. The syntax of the language is brief to a fault. You never have to type an unnecessary character, or even use the Shift key much. Using big abstractions you can write the first version of a program very quickly. Later, when you want to optimize, there’s a really good profiler that tells you where to focus your attention. You can make inner loops blindingly fast, even writing inline byte code if you need to.

| Location: 3359 | Color: yellow |



15. Design and Research

The difference between design and research seems to be a question of new versus good. Design doesn’t have to be new, but it has to be good. Research doesn’t have to be good, but it has to be new. I think these two paths converge at the top: the best design surpasses its predecessors by using new ideas, and the best research solves problems that are not only new, but worth solving. So ultimately design and research are aiming for the same destination, just approaching it from different directions.

| Location: 3383 | Color: yellow |

The customer is always right in the sense that the measure of good design is how well it works for the user. If you make a novel that bores everyone, or a chair that’s horribly uncomfortable to sit in, then you’ve done a bad job, period. It’s no defense to say that the novel or chair is designed according to the most advanced theoretical principles. 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. This focus on the user is a kind of axiom from which most of the practice of good design can be derived, and around which most design issues center.

| Location: 3393 | Color: yellow |

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.

| Location: 3455 | Color: yellow |

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. The same is true in the arts, and particularly in oil painting. Most painters start with a blurry sketch and gradually refine it. If you work this way, then in principle you never have to end the day with something that looks unfinished. Indeed, there is even a saying among painters: “A painting is never finished. You just stop working on it.” This idea will be familiar to anyone who has worked on software.

| Location: 3459 | Color: pink |

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. The designer is human too.

| Location: 3464 | Color: yellow |



Chapter 6

One valuable thing you tend to get only in startups is uninterruptability. Different kinds of work have different time quanta. Someone proofreading a manuscript could probably be interrupted every fifteen minutes with little loss of productivity. But the time quantum for hacking is very long: it might take an hour just to load a problem into your head. So the cost of having someone from personnel call you about a form you forgot to fill out can be huge. This is why hackers give you such a baleful stare as they turn from their screen to answer your question. Inside their heads a giant house of cards is tottering. The mere possibility of being interrupted deters hackers from starting hard projects. This is why they tend to work late at night, and why it’s next to impossible to write great software in a cubicle (except late at night). One great advantage of startups is that they don’t yet have any of the people who interrupt you. There is no personnel department, and thus no form nor anyone to call you about it.

| Location: 3629 | Color: blue |