《Hackers.and.Painters》读书笔记

今年读到最有启发和价值的书,评分4.8分

Preface

Orbitz, the travel web site, managed to break into a market dominated by two very formidable competitors: Sabre, who owned electronic reservations for decades, and Microsoft. How on earth did Orbitz pull this off? Largely by using a better programming language.【更好的编程语言?!】

Some might wonder about “What You Can’t Say” (Chapter 3). What does that have to do with computers? The fact is, hackers are obsessed with free speech. Slashdot, the New York Times of hacking, has a whole section about it. I think most Slashdot readers take this for granted.

Chapter 1

Why Nerds Are Unpopular

But in a typical American secondary school, being smart is likely to make your life difficult. Why? American?】

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.

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.

Alberti, arguably the archetype of the Renaissance Man, writes that“no art, however minor, demands less than total dedication if you want to excel in it.”

Likewise, popular isn’t just something you are or you aren’t, but something you make yourself.

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

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.

If I could go back and give my thirteen year old self some advice, the main thing I’d tell him would be to stick his head up and look around. I didn’t really grasp it at the time, but the whole world we lived in was as fake as a Twinkie.[know the world]

Someone who thinks his feet naturally hurt is not going to stop to consider the possibility that he is wearing the wrong size shoes.[unconscious of the fact]

Another problem, and possibly an even worse one, was that we never had anything real

to work on. Humans like to work; in most of the world, your work is your identity. And all the work we did was pointless, or seemed so at the time.[ pointless]

At best it was practice for real work we might do far in the future, so far that we didn’t even know at the time what we were practicing for.[many are useless]

At best it was practice for real work we might do far in the future, so far that we didn’t even know at the time what we were practicing for. More often it was just an arbitrary series of hoops to jump through, words without content designed mainly for testability.

(The three main causes of the Civil War were. . . . Test: List the three main causes of the Civil War.)

The adults had agreed among themselves that this was to be the route to college. The only way to escape this empty life was to submit to it.

Teenagers seem to have respected adults more then, because the adults were the visible experts in the skills they were trying to learn. Now most kids have little idea what their parents do in their distant offices, and see no connection (indeed, there is precious little) between schoolwork and the work they’ll do as adults.[parents’ work]

Now adults have no immediate use for teenagers. They would be in the way in an office. So they drop them off at school on their way to work, much as they might drop the dog off at a kennel if they were going away for the weekend.

And so most schools do such a bad job of teaching that the kids don’t really take it seriously—not even the smart kids. Much of the time we were all, students and teachers both, just going through the motions.  [school is official]

But teachers like him were individuals swimming upstream. They couldn’t fix the system.

We say that the situation degenerates into a popularity contest. And that’s exactly what happens in most American schools. Instead of depending on some real test, one’s rank depends mostly on one’s ability to increase one’s rank. It’s like the court of Louis XIV. There is no external opponent, so the kids become one another’s opponents.[Rank]

When there is some real external test of skill, it isn’t painful to be at the bottom of the hierarchy. A rookie on a football team doesn’t resent the skill of the veteran; he hopes to be like him one day and is happy to have the chance to learn from him. The veteran

may in turn feel a sense of noblesse oblige. And most importantly, their status depends on how well they do against opponents, not on whether they can push the other down.

Teenage kids are not inherently unhappy monsters. That should be encouraging news to kids and adults both.

Chapter 2

Hackers and 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.

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 it. But 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.

But for the hackers this label is a problem. If what they’re doing is called science, it makes them feel they ought to be acting scientific. So 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.

Unfortunately, beautiful things don’t always make the best subjects for papers. Number one, research must be original—and as anyone who has written a PhD dissertation knows, the way to be sure you’re exploring virgin territory is to to stake out a piece of ground that no one wants. Number two, research must be substantial—and awkward systems yield meatier papers, because you can write about the obstacles you have to overcome in order to get things done. Nothing yields meaty problems like starting with the wrong assumptions. Most of AI is an example of this rule; if you assume that knowledge can be represented as a list of predicate logic expressions whose arguments represent abstract concepts, you’ll have a lot of papers to write about how to make this work. As Ricky Ricardo used to say, “Lucy, you got a lot of explaining to do.”

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.

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

I’ve found that the best sources of ideas are not the other fields that have the word “computer” in their names, but the other fields inhabited by makers. Painting has been a much richer source of ideas than the theory of computation.

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.[the programming language]

[Math and Science]

While we’re on the subject of static typing, identifying with the makers will save us from another problem that afflicts the sciences: math envy. Everyone in the sciences secretly believes that mathematicians are smarter than they are. I think mathematicians also believe this. At any rate, the result is that scientists tend to make their work look as mathematical as possible. In a field like physics this probably doesn’t do much harm, but the further you get from the natural sciences, the more of a problem it becomes.

A page of formulas just looks so impressive. (Tip: for extra impressiveness, use Greek variables.) And so there is a great temptation to work on problems you can treat formally, rather than problems that are, say, important.

If hackers identified with other makers, like writers and painters, they wouldn’t feel tempted to do this. Writers and painters don’t suffer from math envy. They feel as if they’re doing something completely unrelated. So are hackers, I think.

Universities and research labs force hackers to be scientists, and companies force them to be engineers.

When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.[implement and design]

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.

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. There are two problems with this, though. One is that in a startup you have to do so much besides write software.

The other problem with startups is that there is not much overlap between the kind of software that makes money and the kind that’s interesting to write. Programming languages are interesting to write, and Microsoft’s first product was one, in fact, but no one will pay for programming languages now. If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

All makers face this problem. Prices are determined by supply and demand, and there is just not as much demand for things that are fun to work on as there is for things that solve the mundane  problems of individual customers.

More generally, it means you have one kind of work you do for money, and another for love.

This is what open source hacking is all about. What I’m saying is that open source is probably the right model, because it has been independently confirmed by all the other makers.

What else can painting teach us about hacking?

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.

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.

Hackers, likewise, can learn to program by looking at good programs—not just at what they do, but at the source code. One of the less publicized benefits of the open source movement is that it has made it easier to learn to program.

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.

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.

Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too. When it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that’s badly indented, or that uses ugly variable names.

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. When you’re driving a car with a manual transmission on a hill, you have to back off the clutch sometimes to avoid stalling. Backing off can likewise prevent ambition from stalling. In both painting and hacking there are some tasks that are terrifyingly ambitious, and others that are comfortingly routine. It’s a good idea to save some easy tasks for moments when you would otherwise stall.

The example of painting can teach us not only how to manage our own work, but how to work together.[teamwork]

When a piece of code is being hacked by three or four different people, no one of whom really owns it, it will end up being like a common-room. It will tend to feel bleak and abandoned, and accumulate cruft. 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.

Like painting, most software is intended for a human audience.  You have to be able to see things from the user’s point of view.

Boy, was I wrong. It turns out that looking at things from other people’s point of view is practically the secret of success.

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.

Chapter 3

What You Can’t Say

Fashion is mistaken for good design; moral fashion is mistaken for good.

What would  someone coming back to visit us in a time machine have to be careful not to say? That’s what I want to study here. But I want to do more than just shock everyone with the heresy du jour. I want to find general recipes for discovering what you can’t say, in any era.

The Conformist Test

If everything you believe is something you’re supposed to believe, could that possibly be a coincidence? Odds are it isn’t. Odds are you just think whatever you’re told.

The other alternative would be that you independently considered every question and came up with the exact same answers that are now considered acceptable. That seems unlikely, because you’d also have to make the same mistakes. 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.

If you believe everything you’re supposed to now, how can you be sure you wouldn’t also have believed everything you were supposed to if you had grown up among the plantation owners of the pre-Civil War South, or in Germany in the 1930s—or among the Mongols in 1200, for that matter? Odds are you would have.

Back in the era of terms like “well-adjusted,” the idea seemed to be that there was something wrong with you if you thought things you didn’t dare say out loud. This seems backward. Almost certainly, there is something wrong with you if you don’t  think things you don’t dare say out loud.

Trouble

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?

Heresy

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.

Time and Space

So here is another source of interesting heresies. Diff present ideas against those of various past cultures, and see what you get.

You don’t have to look into the past to find big differences. In our own time, different societies have wildly varying ideas of what’s ok and what isn’t. So you can try diffing other cultures’ ideas against ours as well.

Prigs

Most adults, likewise, deliberately give kids a misleading view of the world.

The important thing for our purposes is that, as a result, awell brought-up teenage kid’s brain is a more or less complete collection of all our taboos— and in mint condition, because they’re untainted by experience. Whatever we think that will later turn out to be ridiculous, it’s almost certainly inside that head.

Mechanism

Why Third, I do it because it’s good for the brain. To do good work you need a brain that can go anywhere. And you especially need a brain that’s in the habit of going where it’s not supposed to.

Great work tends to grow out of ideas that others have overlooked, and no idea is so overlooked as one that’s unthinkable.

A good scientist, in other words, does not merely ignore conventional wisdom, but makes a special effort to break it. Scientists go looking for trouble. This should be the m.o. of any scholar, but scientists seem much more willing to look under rocks.

Training yourself to think unthinkable thoughts has advantages beyond the thoughts themselves. It’s like stretching.

Pensieri Stretti

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.

The first rule of Fight Club is, you do not talk about Fight Club.

Closed thoughts and an open face. Smile at everyone, and don’t tell them what you’re thinking.

The problem is, there are so many things you can’t say. If you said them all you’d have no time left for your real work.

The trouble with keeping your thoughts secret, though, is that you lose the advantages of discussion. Talking about an idea leads to more ideas. So the optimal plan, if you can manage it, is to have a few trusted friends you can speak openly to. This is not just a way to develop ideas; it’s also a good rule of thumb for choosing friends. The people you can say heretical things to without getting jumped on are also the most interesting to know.

Viso Sciolto?

Better still, answer “I haven’t decided.” That’s what Larry Summers did when a group tried to put him in this position.

One way to do this is to ratchet the debate up one level of abstraction.

Another way to counterattack is with metaphor.

Best of all, probably, is humor.

Always Be Questioning

When people are bad at math, they know it, because they get the wrong answers on tests. But when people are bad at open mindedness, they don’t know it.

To see fashion in your own time, though, requires a conscious effort. Without time to give you distance, you have to create distance yourself. Instead of being part of the mob, stand as far away from it as you can and watch what it’s doing. And pay especially close attention whenever an idea is being suppressed.

Especially if you hear yourself using them. It’s not just the mob you need to learn to watch from a distance. You need to be able to watch your own thoughts from a distance. That’s not a radical idea, by the way; it’s the main difference between children and adults. When a child gets angry because he’s tired, he doesn’t  know what’s happening. An adult can distance himself enough from the situation to say “never mind, I’m just tired.” I don’t

see why one couldn’t, by a similar process, learn to recognize and discount the effects of moral fashions.

You have to take that extra step if you want to think clearly. But it’s harder, because now you’re working against social customs instead of with them. Everyone encourages you to grow up to the point where you can discount your own bad moods. Few encourage you to continue to the point where you can discount society’s bad moods.

How can you see the wave, when you’re the water? Always be questioning. That’s the only defence. What can’t you say? And why?

Chapter 4

Good Bad Attitude

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.

But they’re wrong. The next generation of computer technology has often—perhaps more often than not—been developed by outsiders.

Civil liberties make countries rich. If you made a graph of GNP per capita vs. civil liberties, you’d notice a definite trend. Could civil liberties really be a cause, rather than just an effect? I think so. I think a society in which people can do and say what they want will also tend to be one in which the most efficient solutions win, rather than those sponsored by the most influential people.

Chapter 5

The Other Road Ahead

The number of possible connections between developers grows exponentially with the size of the group.

I studied click trails of people taking the test drive and found that at a certain step they would get confused and click on the browser’s Back button. (If you try writing web-based applications, you’ll find the Back button becomes one of your most interesting philosophical problems.) So I added a message at that point, telling users they were nearly finished, and reminding them not to click on the Back button. Another great thing about web-based software is that you get instant feedback from changes: the number of people completing the test drive rose immediately from 60% to 90%. And since the number of new users was a function of the number of completed test drives, our revenue growth increased by 50%, just from that change.

You might think that people decide to buy something, and then buy it, as two separate steps.

There is nothing you can do about this conundrum, so the best plan is to go for the smaller customers first. The rest will come in time.

I’m not saying that no one will dominate server-based applications. Someone probably will eventually. But I think there will be a good long period of cheerful chaos, just as there was in the early days of microcomputers. That was a good time for startups. Lots of small companies flourished, and did it by making cool things.

In a startup writing web-based applications, everything you associate with startups is taken to an extreme. You can write and launch a product with even fewer people and even less money. You have to be even faster, and you can get away with being more informal. You can literally launch your product as three guys operating out of an apartment, with a server collocated at an ISP. We did.

Web-based applications offer a straightforward way to outwork your competitors. No startup asks for more.

One thing that might deter you from writing web-based applications is the lameness of web pages as a UI. That is a problem, I admit. There were a few things we would have really liked to add to HTML and HTTP. What matters, though, is that web pages are just good enough.

I feel like I’ve watched the evolution of the Web as closely as anyone, and I can’t predict what’s going to happen with clients. Convergence is probably coming, but where?

How will it all play out? I don’t know. And you don’t have to know if you bet on web-based applications. No one can break that without breaking browsing. The Web may not be the only way to deliver software, but it’s one that works now and will continue to work for a long time. 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.

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.

We had to spend thousands on a server, and thousands more to get SSL. (The only company selling SSL software at the time was Netscape.)

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. Viaweb was supposed to be an online store builder, but we used it to make our own site too. 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.

Now let’s talk about competition. What you’re afraid of is not presumably groups of hackers like you, but actual companies, with offices and business plans and salesmen and so on, right? Well, they are more afraid of you than you are of them, and they’re right. It’s a lot easier for a couple of hackers to figure out how to rent office space or hire sales people than it is for a company of any size to get software written. I’ve been on both sides, and I know. When Viaweb was bought by Yahoo, I suddenly found myself working for a big company, and it was like trying to run through waist-deep water.

Chapter 6

How to Make Wealth

If you wanted to get rich, how would you do it? I think your best bet would be to start or join a startup. That’s been a reliable way to get rich for hundreds of years.

Startups usually involve technology, so much so that the phrase “high-tech startup” is almost redundant. A startup is a small company that takes on a hard technical problem.

Lots of people get rich knowing nothing more than that. You don’t have to know physics to be a good pitcher. But I think it could give you an edge to understand the underlying principles. Why do startups have to be small? Will a startup inevitably stop being a startup as it grows larger? And why do they so often work on developing new technology? Why are there so many startups selling new drugs or computer software, and none selling corn oil or laundry detergent?

The Proposition

Here is a brief sketch of the economic proposition. If you’re a good hacker in your mid twenties, you can get a job paying about $80,000 per year. So on average such a hacker must be able to do at least $80,000 worth of work per year for the company just

to break even. You could probably work twice as many hours as a  corporate employee, and if you focus you can probably get three times as much done in an hour.1 You should get another multiple of two, at least, by eliminating the drag of the pointy-haired middle manager who would be your boss in a big company. Then there is one more multiple: how much smarter are you than your job description expects you to be? Suppose another multiple of three. 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.

If $3 million a year seems high, remember that we’re talking about the limit case: the case where you not only have zero leisure time but indeed work so hard that you endanger your health. 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.

Millions, not Billions

There are a lot of ways to get rich, and this essay is about only one of them. This essay is about how to make money by creating wealth and getting paid for it. There are plenty of other ways to get money, including chance, speculation, marriage, inheritance, theft, extortion, fraud, monopoly, graft, lobbying, counterfeiting, and prospecting. Most of the greatest fortunes have probably involved several of these.

The advantage of creating wealth, as a way to get rich, is not just that it’s more legitimate (many of the other methods are nowillegal) but that it’s more straightforward. You just have to do something people want.

Money Is Not Wealth

Wealth is the fundamental thing. Wealth is stuffwe 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. Whereas if you were in the middle of Antarctica, where there is nothing to buy, it wouldn’t matter how much money you had.

Wealth is what you want, not money. But if wealth is the important thing, why does everyone talk about making money? It is a kind of shorthand: money is a way of moving wealth, and in practice they are usually interchangeable. But they are not the same thing, and unless you plan to get rich by counterfeiting, talking about making money can make it harder to understand how to make money.

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.

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

The Pie Fallacy

A surprising number of people retain from childhood the idea that there is a fixed amount of wealth in the world. There is, in any normal family, a fixed amount of money at any moment. But that’s not the same thing.

When wealth is talked about in this context, it is often described as a pie. “You can’t make the pie larger,” say politicians. When you’re talking about the amount of money in one family’s bank account, or the amount available to a government from one year’s tax revenue, this is true. If one person gets more, someone else has to get less.

This fallacy is usually there in the background when you hear someone talking about how x percent of the population have y percent of the wealth. If you plan to start a startup, then whether you realize it or not, you’re planning to disprove the Pie Fallacy.

What leads people astray here is the abstraction of money. 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.

In restoring your old car you have made yourself richer. You haven’t made anyone else poorer. So there is obviously not a fixed pie. And in fact, when you look at it this way, you wonder why anyone would think there was.

Craftsmen

The people most likely to grasp that wealth can be created are the ones who are good at making things, the craftsmen. Their hand-made objects become store-bought ones. But with the rise of industrialization there are fewer and fewer craftsmen. One of the biggest remaining groups is computer programmers.

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.

In our world, you sink or swim, and there are no excuses.[classical]

Wealth can be created without being sold. Scientists, till recently at least, effectively donated the wealth they created. We are all richer for knowing about penicillin, because we’re less likely to die from infections. Wealth is whatever people want, and not dying is certainly something we want. Hackers often donate their work by writing open source software that anyone can use for free. I am much the richer for the operating system FreeBSD, which I’m running on the computer I’m using now, and so is Yahoo, which runs it on all their servers.

What a Job Is

There are a few differences: life is not as much fun, and you get paid, instead of paying, as you did in college.

Working Harder

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.

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. Measurement alone is not enough. An example of a job with measurement but not leverage is doing piecework in a sweatshop. Your performance is measured and you get paid accordingly, but you have no scope for decisions. An example of a job with both measurement and leverage would be lead actor in a movie.

I think everyone who gets rich by their own efforts will be found to be in a situation with measurement and leverage. 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. All you need to do is be part of a small group working on a hard problem.

Smallness = Measurement

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.

Technology = Leverage

Startups offer anyone a way to be in a situation with measurement and leverage. They allow measurement because they’re small, and they offer leverage because they make money by inventing new technology.

What is technology? It’s technique. It’s the way we all do things. And when you discover a new way to do things, its value is multiplied by all the people who use it. It is the proverbial fishing rod, rather than the fish. That’s the difference between a startup and a restaurant or a barber shop. You fry eggs or cut hair one customer at a time. Whereas if you solve a technical problem that a lot of people care about, you help everyone who uses your solution.

That’s leverage.

If you look at history, it seems that most people who got rich by creating wealth did it by developing new technology.

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. It’s obvious that biotech or software startups exist to solve hard technical problems, but I think it will also be found to be true in businesses that don’t seem to be about technology.

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.

I can remember times when we were just exhausted after wrestling all day with some horrible technical problem. And I’d be delighted, because something that was hard for us would be impossible for our competitors.

This is not just a good way to run a startup. It’s what a startup is.

If you go to a VC with a new idea and ask him to invest in it, one of the first things he’ll ask is, how hard would this be for someone else to develop? That is, how much difficult ground have you put between yourself and potential pursuers?7 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.

One way to put up barriers to entry is through patents. But patents may not provide much protection. Competitors commonly find ways to work around a patent. And if they can’t, they may simply violate it and invite you to sue them. A big companyis not afraid to be sued; it’s an everyday thing for them.

Here, as so often, the best defense is a good offense. If you can develop technology that’s simply too hard for competitors to duplicate, you don’t need to rely on other defenses. Start by picking a hard problem, and then at every decision point, take the harder choice.

The Catch(es)

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.

The other catch is that the payoff is only on average proportionate to your productivity.

A startup is like a mosquito. but a mosquito is designed for one thing: to score. No energy is wasted on defense. 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.

Get Users

I think it’s a good idea to get bought, if you can.

For most people, the most powerful motivator is not the hope of gain, but the fear of loss. For potential acquirers, the most powerful motivator is the prospect that one of their competitors will buy you. 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. In both cases, what it all comes down to is users. 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 a startup, you’re not just trying to solve problems. You’re trying to solve problems that users care about.

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.

The ball you need to keep your eye on here is the underlying principle that wealth is what people want. If you plan to get rich by creating wealth, you have to know what people want. So few businesses really pay attention to making customers happy.

But in technology, you cook one thing and that’s what everyone eats. So any difference between what people want and what you deliver is multiplied. You please or annoy customers wholesale. The closer you can get to what they want, the more wealth you generate.

Wealth and Power

Two things changed. The first was the rule of law. 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. 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.

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.

Developing new technology is a pain in the ass. Without the incentive of wealth, no one wants to do 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 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.

Once you’re allowed to do that, people who want to get rich can do it by generating wealth instead of stealing it The same recipe that makes individuals rich makes countries powerful. Let the nerds keep their lunch money, and you rule the world.

Chapter 7

Mind the Gap

When people care enough about something to do it well, those who do it best tend to be far better than everyone else.

No one complains when a few people surpass all the rest at playing chess or writing novels, but when a few people make more money than the rest, we get editorials saying this is wrong.

I think there are three reasons we treat making money as different: the misleading model of wealth we learn as children; the disreputable way in which, till recently, most fortunes were accumulated; and the worry that great variations in income are somehow bad for society. As far as I can tell, the first is mistaken, the second outdated, and the third empirically false. Could it be that, in a modern democracy, variation in income is actually a sign of health?

The Daddy Model of Wealth

When I was five I thought electricity was created by electric sockets. I didn’t realize there were power plants out there generating it. Likewise, it doesn’t occur to most kids that wealth is something that has to be generated. It seems to be something that flows from parents.

Wealth is the underlying stuff—the goods and services we buy. When you travel to a rich or poor country, you don’t have to look at people’s bank accounts to tell which kind you’re in. You can see wealth—in buildings and streets, in the clothes and the health of the people.

Where does wealth come from? People make 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. And since the ability and desire to create it vary from person to person, it’s not made equally.

When we talk about “unequal distribution of income,” we should also ask, where does that income come from? Who made the wealth it represents? Because to the extent that income varies simply according to how much wealth people create, the distribution may be unequal, but it’s hardly unjust.

Stealing It 

The second reason we tend to find great disparities of wealth alarming is that for most of human history the usual way to accumulate a fortune was to steal it: in pastoral societies by cattle raiding; in agricultural societies by appropriating others’ estates in times of war, and taxing them in times of peace.

The Lever of Technology

The only thing technology can’t cheapen is brand.

Brand is the residue left as the substantive differences between rich and poor evaporate. Is it a problem if technology increases that gap? It doesn’t seem to be so far. As it increases the gap in income, it seems to decrease most other gaps.

Alternative to an Axiom

I’d like to propose an alternative idea: that in a modern society, increasing variation in income is a sign of health. Technology seems to increase the variation in productivity at faster than linear rates. If we don’t see corresponding variation in income, there

are three possible explanations: (a) that technical innovation has stopped, (b) that the people who would create the most wealth aren’t doing it, or (c) that they aren’t getting paid for it.

Will people create wealth if they can’t get paid for it? Only if it’s fun. People will write operating systems for free. But they won’t install them, or take support calls, or train customers to use them. And at least 90% of the work that even the highest tech companies do is of this second, unedifying kind.

But if it were merely a fan we were studying, without all the extra baggage that comes from the controversial topic of wealth, no one would have any doubt that the fan was causing the noise.

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.

You need rich people in your society not so much because in spending their money they create jobs, but because of what they have to do to get  rich. I’m not talking about the trickle-down effect here. I’m not saying that if you let Henry Ford get rich, he’ll hire you as a waiter at his next party. I’m saying that he’ll make you a tractor to replace your horse.

Chapter 8

A Plan for Spam

I think it’s possible to stop spam, and that content-based filters are the way to do it.

 

If we can write software that recognizes their messages, there is no way they can get around that.

And strangely enough, the better your spam filters get, the more dangerous false positives

become, because when the filters are really good, users will be more likely to ignore everything they catch.

I don’t know why I avoided trying the statistical approach for so long. I count the number of times each token (ignoring case, currently) occurs in each corpus. At this stage I end up with two large hash tables, one for each corpus, mapping tokens to number of occurrences.

Next I create a third hash table, this time mapping each token to the probability that an email containing it is a spam, Pspam|w which I calculate as follows:

rg = min(1, 2(good(w)/G)), rb = min(1, bad(w)/B)

Pspam|w = max(.01,min(.99, rb/(rg + rb)))                                                                                                                                                                                                                                                                                   

Norbert Wiener said if you compete with slaves you become a slave, and there is something similarly degrading about competing with spammers.                                      

You could start users with a seed filter, but ultimately each user should have his own per-word probabilities based on the actual mail he receives. This (a) makes the filters more effective, (b) lets each user decide their own precise definition of spam, and © perhaps best of all makes it hard for spammers to tune mails to get through the filters. If a lot of the brain of the filter is in the individual databases, then merely tuning spams to get through the seed filters won’t guarantee anything about how well they’ll get through individual users’ varying and much more trained filters.     Still, anyone who proposes a plan for spam filtering has to be able to answer the question: if the spammers knew exactlywhat you were doing, how well could they get past you? For example, I think that if checksum-based spam filtering becomes a serious obstacle, the spammers will just switch to mad-lib techniques for generating message bodies.

Chapter 9

Taste for Makers                 

Saying that taste is just personal preference is a good way to prevent disputes. The trouble is, it’s not true. You feel this when you start to design things.                                                          

But if your job is to design things, and there is no such thing as beauty, then there is no way to get better at your job.  If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.                                                                 

How has your taste changed? When you made mistakes, what caused you to make them? What have other people learned about design?

Once you start to examine the question, it’s surprising how much different fields’ ideas of beauty have in common. The same principles of good design crop up again and again. 

Good design is simple. You hear this from math to painting.                                                                                                                                                                                                                                                                   Good design is timeless.                                                                                                                                                    Aiming at timelessness is a way to make yourself find the best answer: if you can imagine someone surpassing you, you should do it yourself. Aiming at timelessness is also a way to evade the grip of fashion.

Fashions almost by definition change with time, so if you can make  something that will still look good far into the future, then its appeal must derive more from merit than fashion.  So if you can make something that appeals to people today and would also have appealed to people in 1500, there is a good chance it will appeal to people in 2500.                                                                                                                                                                                           

Good design solves the right problem.                                                                                                                   

Good design is suggestive.                                                                                                                                           

Good design is often slightly funny.                                                                                                                

Good design is hard.                                                                                                                                                           

Good design looks easy.                                                                                                                                      

When people talk about being in “the zone,” I think what they mean is that the spinal cord has the situation under control. Your spinal cord is less hesitant, and it frees conscious thought for the hard problems.                                                                                                                                                                                                                                                                                                                                      Good design uses symmetry.                                                                                                                                        There are two kinds of symmetry, repetition and recursion. Recursion means repetition in subelements, like the pattern of veins in a leaf.                                                                                                   

Good design resembles nature.                                                                                                                                     

Good design is redesign.                                                                                                                                               You have to be able to think, there’s more where that came from.                                                                                                                                                                                                                                                          Good design can copy.                                                                                                                               

Unknowing imitation is almost a recipe for bad design. If you don’t know where your ideas are coming from, you’re probably imitating an imitator.                                                                            

The second phase in the growth of taste is a conscious attempt at originality.                   

Good design is often strange.                                                                                                                                       

Good design happens in chunks.                                                                                                                           

Nothing is more powerful than a community of talented people working on related problems.                                                                                                                                                                                  

Good design is often daring.                                                                                                                                  Intolerance for ugliness is not in itself enough. You have to understand a field well before you develop a good nose for what needs fixing. You have to do your homework. But as you become expert in a field, you’ll start to hear little voices saying, What a hack! There must be a better way.  Don’t ignore those voices. Cultivate them. The recipe for great work is: very exacting taste, plus the ability to gratify it.

Chapter 10

Programming Languages Explained                                                                                                                        

     Machine Language                                                                                                                                                          High-Level Languages                                                                                                                                               Open Source                                                                                                                                                                          Language Wars                                                                                                                                                           Abstractness                                                                                                                                                                               Seat Belts or Handcuffs?                                                                                                                                    One of the more active questions at the moment is static  versus dynamic typing.                                                                                                                                                                                                            Advocates of static typing argue that it helps to prevent bugs and helps compilers to generate fast code (both true). Advocates of dynamic typing argue that static typing restricts what programs you can write (also true).                                                                                

OO                                                                                                                                                                                    Renaissance                                                                                                                                                                  

For the little, everyday problems that programmers spend so much of their time solving, libraries are probably more important than the core language.                                                                                                          

Chapter 11

The Hundred-Year Language                   

Here I want to zoom in on one detail of this picture. What kind of programming language will they use to write the software controlling those flying cars? predict a similar fate for Java. People sometimes send me mail saying, When I say Java won’t turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.There’s good waste, and bad waste. I’m interested in good waste—the kind where, by spending more, we can get simpler designs. How will we take advantage of the opportunities to waste cycles that we’ll get from new, faster hardware? Most data structures exist because of speed. For example, many languages today have both strings and lists. You don’t, really. Strings only exist for efficiency.       The right way to solve that problem is to separate the meaning of a program from the implementation details. Instead of having both lists and strings, have just lists, with some way to give the compiler optimization advice that will allow it to lay out strings as contiguous bytes if necessary.                                                                                                                                      

The word “essay” comes from the French verb “essayer,” which means “to try.” An essay, in the original sense, is something you write to try to figure something out. This happens in software too. I think some of the best programs were essays, in the sense that the authors didn’t know when they started exactly what they were trying to write.                                                                                                                                                                                                                                         Could a programming language go so far as to get rid of numbers as a fundamental data type? I ask this less as a serious question than as a way to play chicken with the future. It’s like the hypothetical case of an irresistible force meeting an immovable object—here, an unimaginably inefficient implementation meeting unimaginably great resources.                      

A language is by definition reusable. The more of your application you can push down into a language for writing that type of application, the more of your software will be reusable.  But although some object-oriented software is reusable, what makes it reusable is its bottom-upness, not its object-orientedness.     As long as we’re talking about the future, we had better talk about parallel computation, because that’s where this idea seems to live. At any given time, it always seems to be something that’s going to happen in the future.              

Now we have two ideas that, if you combine them, suggest interesting possibilities: (1) the hundred-year language could, in principle, be designed today, and (2) such a language, if it existed, might be good to program in today. When you see these ideas laid out like that, it’s hard not to think, why not try writing the hundred-year language now?

Chapter 12

Beating the Averages                                                                                                                                                                                                                                 

In Ansi Common Lisp  I tried to move things along as fast as I could, and even so I didn’t get to macros until page 160.                                                                                                                                                                                                                                                                              

Chapter 13

Revenge of the Nerds                                                                                                                                                                                                                                                 

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.   Lisp and Fortran were the trunks of two separate evolutionary trees, one rooted in math and one rooted in machine architecture. These two trees have been converging ever since.                                                                                                                                                                                                                                                                          

What Made Lisp Different                                                                                                                                  When it was first developed, Lisp embodied nine new ideas. The nine ideas are, in order of their adoption by the mainstream,                                                                                                                             

1. Conditionals. A conditional is an if-then-else construct. We take these for granted now, but Fortran I didn’t have them. It had only a conditional goto closely based on the underlying machine instruction.

2. A function type. In Lisp, functions are a data type just like integers or strings. They have a literal representation, can be stored in variables, can be passed as arguments, and so on.

3. Recursion. Lisp was the first high-level language to support recursive functions.4

4. Dynamic typing. In Lisp, all variables are effectively pointers. Values are what have types, not variables, and assigning values to variables means copying pointers, not what they point to.

5. Garbage-collection.

6. Programs composed of expressions. Lisp programs are trees of expressions, each of which returns a value. This is in contrast to Fortran and most succeeding languages, which distinguish between expressions and statements. This distinction was natural in Fortran I because you could not nest statements. So while you needed expressions for math to work, there was no point in making anything else return a value, because there could not be anything waiting for it. This limitation went away with the arrival of block-structured languages, but by then it was too late. The distinction between expressions and statements was entrenched. It spread from Fortran into Algol and then to both their descendants.

7. Asymbol type. Symbols are effectively pointers to strings stored in a hash table. So you can test equality by comparing a pointer, instead of comparing each character.

8. A notation for code using trees of symbols and constants.                                                             

9. The whole language there all the time. There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime. Running code at read-time lets users reprogram Lisp’s syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp’s use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.                                                                                                                                                  

Centripetal Forces 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. And if you don’t, no one will care how comfortingly orthodox your technology choices were.                                                                                                                                                                                               

A Recipe                                                                                                                                                                                   

So here we have two pieces of information that I think are very valuable. In fact, I know it from my own experience. Number 1, languages vary in power. Number 2, most managers deliberately ignore this.  Between them, these two facts are literally a recipe for making money. ITA is an example of this recipe in action. If you want to win in a software business, just take on the hardest problem you can find, use the most powerful language you can get, and wait for your competitors’ pointy-haired bosses to revert to the mean.    

If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one.                                       

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about “patterns.” I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work.8  When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough—often that I’m generating by hand the expansions of some macro that I need to write.                                                                                              

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.                                                                            

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.                                                                                                      

Notes

Peter Norvig found that 16 of the 23 patterns in Design Patterns were “invisible or simpler” in Lisp (www.norvig.com/design-patterns).                                                                                                     

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*