Coding Horror has a post asking people what their favorite programming quotations are. He throws a sideways reference to Programmers at Work, a book I recently finished reading. I’m one of those annoying people who writes in the margins of books, and one of the things I like to do is collect my favorite quotations so that I can remember them down the road.

These are my favorite quotes from Programmers at Work: Interviews with 19 Programmers Who Shaped the Computer Industry. It is a collection of interviews Susan Lammers did in the early 80s. You can read my full review of the book here.

“I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. Then it becomes a kind of trade-off situation where you have to see if you are better off. I like clear wins. I would bet on improving what we have while maintaining all the benefits and eliminating the drawbacks, rather than introducing new games where there are new benefits and new drawbacks.” Charles Simonyi, P19

“Physics and mathematics, like other respectable disciplines, require that you think clearly to succeed in them. That’s why many successful computer people come from these fields. It’s harder to do what people do nowadays — start in computer science and stay in it — because it’s a very shallow discipline. It doesn’t really force you to exercise your intellectual capabilities enough” Butler Lampson, P27

“… They published a ten-year plan that included a foldout showing lines of development and milestones when breakthroughs would be made. It’s all nonsense because no one knows how to do these things. Some of the problems may be solved within the next ten years — but to have a schedule! The world doesn’t work that way. If you don’t know the answers to the problems, you can’t schedule when you’re going to finish the project.” Butler Lampson, P30

“The most important goal is to define as precisely as possible the interfaces between the system and the rest of the world, as well as the interfaces between the major parts of the system itself. The biggest change in my design style over the years has been to put more and more emphasis on the problem to be solved and on finding techniques to define the interfaces precisely. That pays off tremendously, both in a better understanding of what the program really does, and in identification of the crucial parts. It also help people understand how the system is put together. That’s really the most important aspect of designing a program.” Butler Lampson, P33

“Some people are good programmers because they can handle many more details than most people. But there are a lot of disadvantages in selecting programmers for that reason — it can result in programs that no one else can maintain.” Butler Lampson, P34

“Our aspirations are contstantly increasing, so the development of better abstractions doesn’t make the task of programming much easier: It means we can do more elaborate things. We can do more because the primitives that we are using are much more powerful.” Butler Lampson, P35

“To hell with computer literacy. It’s absolutely ridiculous. Study mathematics. Learn to think. Read. Write. These things are of more enduring value. Learn how to prove theorems. …this skill is transferable to many other things. To study only programming is absurd.” Butler Lampson, P38

“I think a lot before I do anything, and once I do something, I’m not afraid to throw it away. It’s very important that a programmer be able to look at a piece of code like a bad chapter of a book and scrap it without looking back. Never get too enamored with one idea, never hang onto anything tenaciously without being able to throw it away when necessary; that should be the programmer’s attitude.” John Warnock, P47

“Don’t bind early; don’t ever make decisions earlier than you have to. Stay an order of magnitude more general than you think you need, because you will end up needing it in the long term. Get something working very quickly and then be able to throw it away. Learn from small experiments rather than large ones. Don’t go into a two-year development with nothing coming out in the middle. Have something come out every two months, so you can evaluate, regroup, and restart.” John Warnock, P52

What happens when little companies grow up into huge corporations?

“The trick is to learn from the Hewlett-Packard approach: Keep it as twenty different, small companies. Keep breaking it up and never let it become a huge organization, except at some level that nobody cares about. In terms of working relationships, keep the number of people small and their focus localized, project-oriented, so they can work at their best.” John Warnock, P54

“Part of our strategy is getting the programmers to think everything through before they go to the coding phase. Writing the design document is crucial, because a lot of simplification comes when you see problems expressed as algorithms. They’re kind of in the smallest form then, where you can see what the overlap is.” Bill Gates, P74

“The most important part of writing a program is designing the data structures. The second most important part is breaking the various code pieces down.” Bill Gates, P76

“Features are kind of crummy in a way, because the more features you have, the bigger the manual is. And features are only beneficial if people take the time to use them, wheras speed — if you can print the pages faster, or show it on the screen faster, or recalc it faster — that’s worth an incredible amount. If you can give the users a few simple commands and make the program efficient enough to do what they want with those few commands, then you’re much better off. One sign of very good programs is that even internally they follow that philosophy of simplicity. If they want to do something complex, they call the code with simple operations internally, rather than doing the complex operation from scratch.” Bill Gates, P78

“I still think that one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through and understand it.” Bill Gates, P83

“Complicated programs are far easier to write than straightforward programs — the exact opposite of what you’d expect. It’s easy to write complicated programs because you reflect the complexity back onto the user; you force the user to make all the hard decisions.” John Page, P95

“Company employees need to feel ownership of what they’re doing and have psychological ownership of the ideas they’re implementing, otherwise they’re not motivated.” John Page, P97

“You can have either high productivity or a great deal of control. That’s the trade-off programmers and users find themselves making all the time.” John Page, P103

“Flying is a lot like programming. A good pilot gives the passenger a flawless, boring ride, while a good programmer gives the customer a flawless, boring experience on their computer.” John Page, P106

“While you’re working hard on a complicated program, it’s important to exercise. The lack of physical exercise does most programmers in. It causes a loss of mental acuity. It also leads to physical weakness that can heighten the feeling of disillusionment that often comes after the second or third straight programming effort.” Jon Page, P107

“It’s also important to try out the program on users to make sure it solves real users’ needs. And that’s where this company is going astray; it’s ignoring users. They’ve gotten caught up in marketing, and what they’re really fighting are other marketers. All the ads are done by marketers, they’re not done by users saying this is what we need. It’s one marketer, trying to pit his or her skills against another marketer, so they’re fighting the battle of the specs.” C. Wayne Ratliff, P125

What would be your advice to young programmers?

“Don’t assume you know all that much, and try to learn and question the assumptions. Have a lot of confidence, but stay modest and assume you’re doing something wrong. Get just enough guilt — not too much or you’ll be afraid to do anything — but enough to develop an aesthetic sense. Try to develop a deeper understanding.” Bob Frankston, P159

“Bugs are often characteristic of a bad interface between subsystems, which is frequently a result of inadequate communication among people when they design the subsystems. When a bug is found, there is a tendency to handle it within the subsystem and not look at the program as a whole.” Ray Ozzie, P186

“Programming is the ultimate field ofr someone who likes to tinker. Tinkering requires tools. Electrical engineers have various components they can put together to build something. But they’re constrained by the availability of physical equipment. With a computer, if you can think about it, you can do it. You can design your own tools or create the parts as you go along. If you don’t like something, you can just change it or rewrite it. It’s a wide-open tool box, given the resource, the computer. The only limiting factors are the amount of time it takes the computer to do the task and the amount of time it takes you to write the program.” Ray Ozzie, P188

“I’ve seen many intelligent people who are just not practical. They get lost pursuing some academic goal that is totally useless. Being practical is important to good programming. You must be able to guess accurately how long it will take to complete a project, have the ability to calculate what can and cannot be done in that time, and then do it, resisting the temptation to go off and do other things. Practicality is important when you’re trying to make every piece of work the best because you always have a limited amount of time to work on it. It’s easy to triple the time to complete a project when you’re consumed with making it the ultimate in elegance.” Peter Roizen, P193

“If you’re going to do anything well, you need to have a serious interest in it. If you don’t care, all the talent in the world will still produce a lousy result. If you do care, you need only one-third the talent to produce something decent.” Peter Roizen, P196

“Picture yourself driving your car. Let’s say that every Thursday the gas pedal and the brake pedal are interchanged. It would drive you up the wall, or through it. You couldn’t live with it. Yet our computers change things around all the time by using “modes”. A system should be “modeless”. The same user action should always have the same effect.” Jef Raskin, P243