Bill Clementson's Blog

Hackers & Painters

Thursday, July 15, 2004

Ahhh, the joys of modern air travel. The combination of a 6 hour flight delay (why do airlines bother to ask you for your contact phone number if they don't bother to ring you?) and a 4 hour flight from Boston to Denver meant that I was able to fit in a bit of reading time on my way home last night. I hadn't expected to do much reading this trip but had brought along Paul Graham's book Hackers & Painters just in case. Although most of the essays are on his web site in an early form, they have been rewritten (with some additional essays added) for this book. Reading them all in one sitting reminded me why I had liked his individual essays when they were originally made available on his web site. Also, the 10 hours in between arriving at Logan Airport and finally landing in Denver meant that I had a lot more reading time for this particular book than I would normally have had and thus picked up some nice little tidbits that I otherwise probably would have missed. For example, the index has the following humorous entry: suits gorilla 25 law 45, 102 reign of, at Apple 228 salesmen's 76 technical decisions by 74, 192 There are also a few humorous definitions (not sure if these are meant to be humorous of if this is just my own warped, sleep-deprived sense of humor) in the glossary: premature optimization Tuning a program for performance before you're finished writing it. The software equivalent of marrying young. recursive An algorithm that refers to itself. A policeman's algorithm for interrogating people is recursive: ask the person if they know about the crime, or if they know anyone who does, and if they do, interrogate them too. string A sequence of characters, usually denoted "like this". uptime Percentage of time a computer, particularly a server, is doing what it is supposed to. Also, the time since a computer last crashed. Seriously, though, Paul's book is an excellent "ideas" book. Hackers & Painters spans a range of related topics including hacking, startups, Lisp, programming languages, nerds, creativity, and ways of thinking. Rather than attempt to summarize the book, I'll let quotes from the book provide a flavor. Here are some of the quotes that resonnated with me (not a comprehensive list by any means) as I read the book: "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." P 20 "There are worse things than having people misunderstand your work. A worse danger is that you will yourself misunderstand your work." P21 "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." P21 "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." P22 "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." P23 "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 thing things you don't dare say out loud." P35 "Great work tends to grow out of ideas that others have overlooked, and no idea is so overlooked as one that's unthinkable." P43 "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." P44 "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." P45 "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?" P49 "Ugly and imaginative solutions have something in common: they both break the rules." P50 "There are only two things you have to know about business: build something users love, and make more than you spend." P84 "Economically, you can think of a startup as a way to compress your whole working life into a few years." P87 "Someone graduating from college thinks, and is told, that he needs to get a job, as if the important thing were becoming a member of an institution. 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. For most people the best plan probably is to go to work for some existing company. But it is a good idea to understand what's happening when you do this. A job means doing something people want, averaged together with everyone else in that company." P95 "Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs." P101 "A startup is like a mosquito. A bear can absorb a hit and a crab is armored against one, but a mosquito is designed for one thing: to score. No energy is wasted on defense. The defense of mosquitos, as a species, is that there are a lot of them, but this is little consolation to the individual mosquito." P103 "It would have been a bargain to buy us at an early stage, but companies doing acquisitions are not looking for bargains. A company big enough to acquire startups will be big enough to be fairly conservative, and within the company the people in charge of acquisitions will be among the more conservative, becuase they are likely to be business school types who joined the company late. They would rather overpay for a safe choice. So it is easier to sell an established startup, even at a large premium, than an early-stage one." P104 "Remember what a startup is, economically: a way of saying, I want to work faster." P107 "The problem with working slowly is not just that technical innovation happens slowly. It's that it tends not to happen at all. It's only when you're deliberately looking for hard problems, as a way to use speed to the greatest advantage, that you take on this kind of project. Developing new technology is a pain in the ass. It is, as Edison said, one percent inspiration and ninety-nine percent perspiration." P107 "It seems strange to have to emphasize simplicity. You'd think simple would be the default. Ornate is more work. ... When you're forced to be simple, you're forced to face the real problem. When you can't deliver ornament, you have to deliver substance." P133 "If you want to discover great new things, then instead of turning a blind eye to the places where conventional wisdom and truth don't quite meet, you should pay particular attention to them." P144 "In practice I think it's easier to see ugliness than to imagine beauty. Most of the people who've made beautiful things seem to have done it by fixing something they thought ugly. Great work usually seems to happen because someone sees something and thinks, I could do better than that." P145 "Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today." P163 "When you choose technology, you have to ignore what other people are doing, and consider only what will work best." P170 "Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway. What were the results of this experiment? Somewhat surprisingly, it worked." P172 "What's so great about Lisp? And if Lisp is so great, why doesn't everyone use it? These sound like rhetorical questions, but actually they have staightforward answers. Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available. And the reason everyone doesn't use it is that programming languages are not merely technologies, but habits of mind as well, and nothing changes slower." P174 "Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one." P175 "After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough." P176 "There may be more to that old man hobbling along on his crutches than meets the eye." P178 "Lisp's power is multiplied by the fact that your competitors don't get it. If you think of using Lisp in a startup, you shouldn't worry that it isn't widely understood. You should hope that it stays that way. And it's likely to. It's the nature of programming languages to make most people satisfied with whatever they currently use." P178 "Obviously, the median language has enourmous momentum. I'm not proposing that you can fight this powerful force. What I'm proposing is exactly the opposite: that, like a practitioner of Aikido, you can use it against your opponents." P179 "So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn't get stale. The right thing to compare Lisp to is not 1950s hardware but the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort." P186 "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." P188 "If you start a startup, don't design your product to please VCs or potential acquirers. Design your product to please 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." P192 "Technology often should be cutting-edge. In programming languages, as Erann Gat has pointed out, what 'industry best practice' actually gets you is not the best, but merely the average." P194 "It may be that the majority of programmers can't tell a good language from a bad one. But that's no different with any other tool. It doesn't mean that it's a waste of time to try designing a good language. Expert hackers can tell a good language when they see one, and they'll use it. Expert hackers are a tiny minority, admittedly, but that tiny minority write all the good software, and their influence is such that the rest of the programmers will tend to use whatever language they use." P201 "Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it." P214 "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." P221 "Design means making things for humans. But it's not just the user who's human. The designer is human too." P221 "The people I know who do great work think that they suck, but that everyone else sucks more." P225 "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." P229 "If you have two choices, choose the harder." P230 "Blub Paradox The inability to understand the power of programming languages more powerful than the ones you're used to thinking in." P242 "Brook's Hypothesis That the number of lines of code programmers can produce per day is constant, regardless of the language they're producing." P242 Definitely a good book for a long trip.