Like many others, Paul Graham’s essays introduced me to startups. I still remember sitting in a class lecture mesmerized by his words—not paying attention to anything else.
Recently, I started to re-read them from the beginning. (Starting with Programming Bottom-Up.) What follows are my favorite quotes.
Design and Research (Jan 2003)
Design doesn’t have to be new, but it has to be good. Research doesn’t have to be good, but it has to be new.
Taste for Makers (Feb 2002)
It’s rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.
Succinctness is Power (May 2002)
In fact, the most accurate measure of the relative power of programming languages might be the percentage of people who know the language who will take any job where they get to use that language, regardless of the application domain.
Revenge of the Nerds (May 2002)
If you start a startup, don’t design your product to please VCs or potential acquirers. Design your product to please the 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.
In programming languages, as Erann Gat has pointed out, what “industry best practice” actually gets you is not the best, but merely the average.
Why Arc Isn’t Especially Object-Oriented
But it seems more dangerous to put stuff in that you’ve never needed because it’s thought to be a good idea.
The Other Road Ahead (Sep 2001)
Ordinary users shouldn’t even know the words “operating system,” much less “device driver” or “patch.”
Being Popular (May 2001)
All you have to do is keep telling your story, and eventually people will start to hear. It’s not when people notice you’re there that they pay attention; it’s when they notice you’re still there.
Five Questions about Language Design (May 2001)
I think anything that really smart people really love is worth paying attention to.
Beating the Averages (April 2001)
If you ever do find yourself working for a startup, here’s a handy tip for evaluating competitors. Read their job listings. Everything else on their site may be stock photos or the prose equivalent, but the job listings have to be specific about what they want, or they’ll get the wrong candidates.
Java’s Cover (April 2001)
It may seem cavalier to dismiss a language before you’ve even tried writing programs in it. But this is something all programmers have to do. There are too many technologies out there to learn them all.
Programming Bottom-Up (1993)
[…] the productivity of a group of programmers does not grow linearly with its size. As the size of the group increases, the productivity of individual programmers goes down.
Interestingly enough my Intro to Computer Science course linked to several of Paul Graham’s essays on Lisp. (The course was taught using DrRacket, a close cousin of Lisp.)
But I did not discover the essays (or startups) until a year later!
Hey, in 2011, startups weren’t as fashionable as today.