paul graham quotes

One of the most dangerous illusions you get from school is the idea that doing
great things requires a lot of discipline. Most subjects are taught in such a
boring way that it's only by discipline that you can flog yourself through
them. So I was surprised when, early in college, I read a quote by Wittgenstein
saying that he had no self-discipline and had never been able to deny himself
anything, not even a cup of coffee.
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. One still hasn't sent out his half of the thank-you notes from
his wedding, four years ago. Another has 26,000 emails in her inbox.
I'm not saying you can get away with zero self-discipline. You probably need
about the amount you need to go running. I'm often reluctant to go running, but
once I do, I enjoy it. And if I don't run for several days, I feel ill. It's
the same with people who do great things. They know they'll feel bad if they
don't work, and they have enough discipline to get themselves to their desks to
start working. But once they get started, interest takes over, and discipline
is no longer necessary.

Paul Graham - http://www.paulgraham.com/hs.html

If you go to see Silicon Valley, what you'll see are buildings. But it's the
people that make it Silicon Valley, not the buildings. I read occasionally
about attempts to set up "technology parks" in other places, as if the active
ingredient of Silicon Valley were the office space. An article about Sophia
Antipolis bragged that companies there included Cisco, Compaq, IBM, NCR, and
Nortel. Don't the French realize these aren't startups?

Building office buildings for technology companies won't get you a silicon
valley, because the key stage in the life of a startup happens before they want
that kind of space. The key stage is when they're three guys operating out of
an apartment. Wherever the startup is when it gets funded, it will stay. The
defining quality of Silicon Valley is not that Intel or Apple or Google have
offices there, but that they were started there.

So if you want to reproduce Silicon Valley, what you need to reproduce is those
two or three founders sitting around a kitchen table deciding to start a
company. And to reproduce that you need those people.

Paul Graham - "How to Be Silicon Valley"
http://www.paulgraham.com/siliconvalley.html

Hacking predates computers. When he was working on the Manhattan Project,
Richard Feynman used to amuse himself by breaking into safes containing
secret documents. This tradition continues today. When we were in grad
school, a hacker friend of mine who spent too much time around MIT had his
own lock picking kit. (He now runs a hedge fund, a not unrelated
enterprise.)

It is sometimes hard to explain to authorities why one would want to do such
things. Another friend of mine once got in trouble with the government for
breaking into computers. This had only recently been declared a crime, and
the FBI found that their usual investigative technique didn't work. Police
investigation apparently begins with a motive. The usual motives are few:
drugs, money, sex, revenge. Intellectual curiosity was not one of the
motives on the FBI's list. Indeed, the whole concept seemed foreign to them.

Paul Graham
The Word "Hacker" - http://www.paulgraham.com/gba.html

If you work your way down the Forbes 400 making an x next to the name of
each person with an MBA, you'll learn something important about business
school. You don't even hit an MBA till number 22, Phil Knight, the CEO of
Nike. There are only four MBAs in the top 50. What you notice in the Forbes
400 are a lot of people with technical backgrounds. Bill Gates, Steve Jobs,
Larry Ellison, Michael Dell, Jeff Bezos, Gordon Moore. The rulers of the
technology business tend to come from technology, not business. So if you
want to invest two years in something that will help you succeed in
business, the evidence suggests you'd do better to learn how to hack than
get an MBA.

Paul Graham
How to Start a Startup - http://www.paulgraham.com/start.html

In the discussion about issues raised by Revenge of the Nerds on the LL1
mailing list, Paul Prescod wrote something that stuck in my mind.

Python's goal is regularity and readability, not succinctness.

On the face of it, this seems a rather damning thing to claim about a
programming language. As far as I can tell, succinctness = power. If so, then
substituting, we get

Python's goal is regularity and readability, not power.

and this doesn't seem a tradeoff (if it is a tradeoff) that you'd want to make.
It's not far from saying that Python's goal is not to be effective as a
programming language.

Paul Graham - "Succinctness is Power"
http://www.paulgraham.com/power.html

For example, I was taught in college that one ought to figure out a program
completely on paper before even going near a computer. I found that I did
not program this way. I found that I liked to program sitting in front of a
computer, not a piece of paper. Worse still, instead of patiently writing
out a complete program and assuring myself it was correct, I tended to just
spew out code that was hopelessly broken, and gradually beat it into shape.
Debugging, I was taught, was a kind of final pass where you caught typos and
oversights. The way I worked, it seemed like programming consisted of
debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't
hold my pencil the way they taught me to in elementary school. If I had only
looked over at the other makers, the painters or the architects, I would
have realized that there was a name for what I was doing: sketching. As far
as I can tell, the way they taught me to program in college was all wrong.
You should figure out programs as you're writing them, just as writers and
painters and architects do.

Paul Graham
"Hackers and Painters" - http://www.paulgraham.com/hp.html

I think that, like species, languages will form evolutionary trees, with
dead-ends branching off all over. We can see this happening already. Cobol,
for all its sometime popularity, does not seem to have any intellectual
descendants. It is an evolutionary dead-end-- a Neanderthal language.

I predict a similar fate for Java. People sometimes send me mail saying,
"How can you say that Java won't turn out to be a successful language? It's
already a successful language." And I admit that it is, if you measure
success by shelf space taken up by books on it (particularly individual
books on it), or by the number of undergrads who believe they have to learn
it to get a job. 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.

This is just a guess. I may be wrong. My point here is not to dis Java, but
to raise the issue of evolutionary trees and get people asking, where on the
tree is language X? The reason to ask this question isn't just so that our
ghosts can say, in a hundred years, I told you so. It's because staying
close to the main branches is a useful heuristic for finding languages that
will be good to program in now.

Paul Graham - http://www.paulgraham.com/hundred.html

I only discovered this myself quite recently. When Yahoo bought Viaweb, they
asked me what I wanted to do. I had never liked the business side very much,
and said that I just wanted to hack. 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.

This seems to be the default plan in big companies. They do it because it
decreases the standard deviation of the outcome. Only a small percentage of
hackers can actually design software, and it's hard for the people running a
company to pick these out. 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.

Paul Graham

The people I've met who do great work... 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.

Paul Graham
"Great Hackers" (later edited out) - http://xrl.us/ho9c

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.

Paul Graham
"What You'll Wish You'd Known" (Advice for High School Kids)
http://www.paulgraham.com/hs.html#fb10

This isn't just something that happens with programming languages. It's a
general historical trend. As technologies improve, each generation can do
things that the previous generation would have considered wasteful. People
thirty years ago would be astonished at how casually we make long distance
phone calls. People a hundred years ago would be even more astonished that a
package would one day travel from Boston to New York via Memphis.

Paul Graham - "The Hundred-Year Language"
http://www.paulgraham.com/hundred.html