PaulGraham

Paul Graham writes interesting stuff. His essays are full of good quote material. I recommend visiting his homepage every month or two and reading his latest essays.

http://www.paulgraham.com/

He also wrote two important books ¹. One of them is a Common Lisp intro and reference book, and the other dives right into what makes Common Lisp a great language. The book is called *On Lisp* and available for download from his site. ² He also has other interesting pages on his site, such as the one describing the features that made Lisp unique back when it got started. ³

¹

²

³

Quotes from The Age of the Essay

These quotes are from Paul Graham’s essay *The Age of the Essay* ⁴. It’s about how the study of literature and learning how to compose an essay was conflated some decades ago and how this results in high school students writing boring essays about literature instead of interesting things:

⁴

[...]due to a series of historical accidents the teaching of writing has gotten mixed together with the study of literature. And so all over the country students are writing not about how a baseball team with a small budget might compete with the Yankees, or the role of color in fashion, or what constitutes a good dessert, but about symbolism in Dickens.

Quotes from Hackers and Painters

These quotes are from Paul Graham’s essay *Hackers and Painters* ⁵. This is one of the essays that didn’t captivate me when I started reading it, so I decided to do some BackwardsReading.

⁵

BackwardsReading

Unfortunately very true:

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.

I feel the same:

It drives me crazy to see code that’s badly indented, or that uses ugly variable names.

I don’t agree with his argument for code ownership. I guess PG believes that code ownership will make sure that owners can carefully craft code into something they really love, and therefore, it will be good. From my experience, however, my creativity does not work that well (see BeingCreative): I work best if I can take other peoples’ code, and I enjoy work most when I can look at code together with other people. That is why I like PairProgramming as described in the Xtreme Programming (XP) paradigm.

BeingCreative

PairProgramming

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.

This is exactly what happened to me:

Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who’ve sworn off Perl after such experiences.

I like this footnote:

A good programming language ought to be better for explaining software than English. You should only need comments when there is some kind of kludge you need to warn readers about, just as on a road there are only arrows on parts with unexpectedly sharp curves.

Much later I also read this interesting rebuttal.

rebuttal

Quotes from Great Hackers

• *Infrastructure**: What do hackers want? Like all craftsmen, hackers like good tools. In fact, that’s an understatement. Good hackers find it unbearable to use bad tools. They’ll simply refuse to work on projects with the wrong infrastructure.

• *Language**: When you decide what infrastructure to use for a project, you’re not just making a technical decision. You’re also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you’re also choosing a community. The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.

• *Open Source**: Great hackers also generally insist on using open source software. Not just because it’s better, but because it gives them more control. Good hackers insist on control. This is part of what makes them good hackers: when something’s broken, they need to fix it. You want them to feel this way about the software they’re writing for you. You shouldn’t be surprised when they feel the same way about the operating system.

• *Office**: The mere prospect of being interrupted is enough to prevent hackers from working on hard problems. If you want to get real work done in an office with cubicles, you have two options: work at home, or come in early or late or on a weekend, when no one else is there. Don’t companies realize this is a sign that something is broken? An office environment is supposed to be something you work in, not something you work despite.

• *Home**: They have a sofa they can take a nap on when they feel tired, instead of sitting in a coma at their desk, pretending to work. There’s no crew of people with vacuum cleaners that roars through every evening during the prime hacking hours. There are no meetings or, God forbid, corporate retreats or team-building exercises. And when you look at what they’re doing on that computer, you’ll find it reinforces what I said earlier about tools. They may have to use Java and Windows at work, but at home, where they can choose for themselves, you’re more likely to find them using Perl and Linux.

• *Taste**: The problem is not so much the day to day management. Really good hackers are practically self-managing. The problem is, if you’re not a hacker, you can’t tell who the good hackers are.

• *Problems**: It’s pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones.

• *Tools**: Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department.

• *Others**: It seems like the only way to judge a hacker is to work with him on something.

• *Great Work**: The people I’ve met who do great work rarely think that they’re doing great work. They generally feel that they’re stupid and lazy, that their brain only works properly one day out of ten, and that it’s only a matter of time until they’re found out.

• *Job**: Try to keep the sense of wonder you had about programming at age 14. If you’re worried that your current job is rotting your brain, it probably is.

Quotes from What You’ll Wish You’d Known

• *Discipline**: Now I know a number of people who do great work, and it’s the same with all of them. They have little discipline. They’re all terrible procrastinators and find it almost impossible to make themselves do anything they’re not interested in.

• *Rebellion**: Rebellion is almost as stupid as obedience. In either case you let yourself be defined by what they tell you to do. The best plan, I think, is to step onto an orthogonal vector. Don’t just do what they tell you, and don’t just refuse to. Instead treat school as a day job. As day jobs go, it’s pretty sweet. You’re done at 3 o’clock, and you can even work on your own stuff while you’re there.

• *Projects**: Put in time how and on what? Just pick a project that seems interesting: to master some chunk of material, or to make something, or to answer some question. Choose a project that will take less than a month, and make it something you have the means to finish. Do something hard enough to stretch you, but only just, especially at first. If you’re deciding between two projects, choose whichever seems most fun. If one blows up in your face, start another. Repeat till, like an internal combustion engine, the process becomes self-sustaining, and each project generates the next one. (This could take years.)

• *Adults**: Your teachers are always telling you to behave like adults. I wonder if they’d like it if you did. You may be loud and disorganized, but you’re very docile compared to adults. If you actually started acting like adults, it would be just as if a bunch of adults had been transposed into your bodies. Imagine the reaction of an FBI agent or taxi driver or reporter to being told they had to ask permission to go the bathroom, and only one person could go at a time. To say nothing of the things you’re taught. If a bunch of actual adults suddenly found themselves trapped in high school, the first thing they’d do is form a union and renegotiate all the rules with the administration.