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