Paul Graham: On Determination & Success, Hard Work, Wealth Creation, Startups, Programming and Art.
Paul Graham is a programmer, writer, and thinker, mostly known as the co-founder of Y Combinator, the world’s most successful startup incubator. In 2004 he released an anthology called “ Hackers and Painters” which explores a variety of topics, from social and cultural issues to technical aspects of programming languages.
Graham after graduating in computer science started studying painting at the Rhode Island School of Design and at the Academia di Belle Arti in Florence. He developed his career and identity by straddling two dichotomies: technologist - artist, but also entrepreneur - writer.
The co-founder of Y Combinator decided to follow his authentic interests. And combining his art background with technical genius helped him become one of the most successful entrepreneurs, investors, and writers in Silicon Valley.
Paul Graham is a comprehensively gifted and genuinely curious polymath who developed interesting thought patterns and points of view that inspire people and touch a variety of topics. Considering how his essays had a great influence on my thinking, I decided to gather his thoughts and put them into a consistent blog post. Enjoy!
1. Determination and Success.
“Like all investors, we spend a lot of time trying to learn how to predict which startups will succeed (…) We learned quickly that the most important predictor of success is determination ”
Determination is the crucial feature of any success. Paul Graham in his widely-spread essay called “The anatomy of determination“ was trying to break it down in the broader context, highlighting the key components of how determination works and how to take advantage of understanding it.
Paul Graham notices that we often overestimate talent and underestimate the power of determination. The purest and simplest form of determination is sheer willfulness. In short, it means that if you want something, you have to achieve it, no matter what. Talent and the pure genius’ imagination moments are good PR stories that often are the opposite of how reality looks and ignore the crucial aspect of determination.
“There are plenty of people as smart as Bill Gates who achieve nothing. In most domains, talent is overrated compared to determination—partly because it makes a better story, partly because it gives onlookers an excuse for being lazy, and partly because after a while determination starts to look like talent.”
The components of determination are: willfulness, discipline, and ambition. The good news is that you can improve at least two of these components.
A successful programmer and writer stated that a good deal of willfulness must be inborn. However, circumstances are a good tool that we can use to alter and improve willfulness.
On a higher level, it seems that our nature is still more crucial and deterministic than circumstances, although we should work on our environment to improve the state of things, even if it’s a small change.
it’s good to have the three elements of determination at a satisfactory level. Paul Graham stated:
“Bad circumstances can break the spirit of a strong-willed person“
Another element that is also the most malleable is the discipline that we can master. And this has further implications that we can benefit from. Because if discipline can be cultivated, we have the power to influence and guide our course of life. Graham added:
“If determination is effectively the product of will and discipline, then you can become more determined by being more disciplined.“
Strong will, a great environment with cultivated discipline empower our determination which means that we can directly increase our odds of succeed. Paul Graham shared a great analogy on that topic:
“We can imagine will and discipline as two fingers squeezing a slippery melon seed. The harder they squeeze, the further the seed flies, but they must both squeeze equally or the seed spins off sideways.“
The final element of determination is ambition, which seems to be also quite workable.
“If willfulness and discipline are what get you to your destination, ambition is how you choose it.“
To our advantage, ambition seems to be pretty malleable, and we can increase the state of being ambitious by doing great things. It may seem counterintuitive, but you can increase your ambition by simply working hard on your goals. In short, our achievements allow us to gain confidence in doing the next and more challenging steps, which in the long-term sets us in the right direction.
Finally, Graham encourages us to start liking things we are not optimistic about because most types of work have at least one aspects that we don't like.
2. On how to work hard.
“One thing I know is that if you want to do great things, you'll have to work very hard. I wasn't sure of that as a kid. And the reason famous adults seemed to do things effortlessly was years of practice; they made it look easy.“
It might seem that's not too much to talk about hard work, but counter-intuitively as often is Graham's approach, there is a left space to add valuable thoughts on putting in the work.
As in the previous example on determination, Paul Graham also breaks down the hard work into three components that influence our great work: natural ability, practice, and effort. And, obviously, it’s better to have all three ingredients at a decent level.
“Bill Gates, for example, was among the smartest people in business in his era, but he was also among the hardest working. "I never took a day off in my twenties," he said. "Not one."“
We can deduce that we need both workable components on a decent level: practice and effort. And since you don’t have an influence on really how much natural ability you have, great work comes down to working as hard as you can.
The problem we face with working hard is that often it’s not clearly defined nor imposed how to move towards goals. You’ll need a lot of discipline, and probably you will learn as it goes. However, hard work is not a lottery ticket, and there are things you can do to influence your work and increase your odds of success.
One of the things you can do in terms of hard work is to follow your inner guide and sense of duty. For example, Graham following his guts and inner voice decided to stop watching TV at the age of 13 to be more focused on productive things.
And you can’t be sure if your work moves you forward, but you can be sure that you’re going nowhere without working hard. So we can imply that is worth following your gut feelings when it comes to hard work, but it’s not a one-size-fits-all solution. As a successful polymath and venture capitalist, Graham wrote:
“The most basic level of which is simply to feel you should be working without anyone telling you to. Now, when I'm not working hard, alarm bells go off. I can't be sure I'm getting anywhere when I'm working hard, but I can be sure I'm getting nowhere when I'm not, and it feels awful. “
Additionally, it’s worth having a deep interest in what you do, since it makes people work harder than any amount of discipline can. However, it can be harder to discover your interests than your talents.
The best test of whether it's worthwhile to work on something is whether you find it interesting. That may sound like a dangerously subjective measure, but it's probably the most accurate one you're going to get. You're the one working on the stuff. Who's in a better position than you to judge whether it's important, and what's a better predictor of its importance than whether it's interesting?
Earlier, I mentioned that when it comes to working hard is worth following your inner voice. To find if something is interesting, you have to have a similar approach, which means that it’d be good to be honest with yourself. Here’s what Graham recommends to do:
For this test to work, though, you have to be honest with yourself. Indeed, that's the most striking thing about the whole question of working hard: how at each point it depends on being honest with yourself.
The venture capitalist goes further in the concept of being honest and encourages us not to lie and procrastinate. He considers procrastination as a form of lying.
Additionally, Graham recommends working on increasing our level of discipline, which translates directly to the ability not to get distracted and not to give up when things go wrong. And it has a significant effect on our great and hard work.
“But if you're consistently honest and clear-sighted, it will automatically assume an optimal shape, and you'll be productive in a way few people are.“
Working hard is a complex and dynamic system consisting of natural ability, practice, and effort. However, we can improve that system by being honest, following gut feelings, not getting distracted, and working on interesting things.
3. Wealth creation
“The same recipe that makes individuals rich makes countries powerful. Let the nerds keep their money launch, and you rule the world.“
Paul Graham has written several essays on the subject of broadly understood wealth. Additionally, what is worth noting is that his way of thinking about wealth goes beyond narrow points of view. He captured the idea of wealth in the bigger context, combining his knowledge and experience with startups, history, and the economy.
Graham connects many areas and gives a broader picture of wealth creation that is firstly pragmatic from the individual perspective and secondly insightful from the global perspective, providing information on how wealth has changed throughout the centuries. One of the most popular wealth-oriented essays written by Graham is “How to make wealth“ and “How people get rich now“.
The wealth we used to see is quite different from the wealth made these days. The main difference between wealth creation in the old days and today is the source. Once wealth came from an inheritance and these days from starting a company:
“In 1982 the most common source of wealth was inheritance. Of the 100 richest people, 60 inherited from an ancestor. There were 10 du Pont heirs alone […] How are people making these new fortunes? Roughly 3/4 by starting companies and 1/4 by investing. Of the 73 new fortunes in 2020, 56 derive from founders' or early employees' equity (52 founders, 2 early employees, and 2 wives of founders), and 17 from managing investment funds.”
Additionally, there’s also a transition in what companies are making the most wealth. For example, companies that brought the most wealth in the eighties operated in the oil and real estate industry. But today's unicorns are born in the tech sphere. And it provides conclusions about the structure and how to scale companies using the technology.
Technology enables to drive down the cost of building products and acquiring customers, which led to shifting the balance of power between founders and investors:
Back when starting a startup meant building a factory, you needed investors' permission to do it at all. But now investors need founders more than founders need investors, and that, combined with the increasing amount of venture capital available, has driven up valuations.
The further conclusions regarding the technology and its effects are that the decreasing cost of starting a startup increase the number of founders and eventually rich people. On top of that, the scale that technology brings allows today’s companies to grow faster than they used to.
This trend has been running for a long time. IBM, founded in 1896, took 45 years to reach a billion 2020 dollars in revenue. Hewlett-Packard, founded in 1939, took 25 years. Microsoft, founded in 1975, took 13 years. Now the norm for fast-growing companies is 7 or 8 years.
That's why founders sometimes get so rich so young now. The low initial cost of starting a startup means that founders can start young, and the fast growth of today's companies means that if they succeed they could be surprisingly rich just a few years later.
Paul Graham also notices an existing difference between the essence of wealth and what people mistakenly consider wealth. Tech enthusiast says that most people view money as wealth, but the reality is quite different, and what we should want is wealth, not money. However, in practice, these things are highly interchangeable.
“Money is just a convenient way of trading one form of wealth for another. Welath is the underlying stuff the good and services we buy“
Wealth is related to doing something that people want. Since you made what people want, you get a reward, and probably you got rewarded with money. It implies certain conclusions, and Graham shares a piece of advice, especially towards young people. After you graduate you don’t necessarily need to get a job and join the company, but you should be focused on doing things that people may need:
“Someone graduating from college thinks, and is told, that he needs to get a job, as if the important thing were becoming a member of an institution. A more direct way to put it would be: you need to start doing something people want. You don't need to join a company to do that. […] For most people the best plan probably is to go to work for some existing company. But it is a good idea to understand what's happening when you do this. A job means doing something people want, averaged together with everyone else in that company. “
Besides doing what people want, to get rich, Graham advises seeking out two things: measurement and leverage. You have to be in a position where it’s easy to measure your performance, and you're capable of making a big effect by doing your work. Examples of jobs that meet these two conditions are CEOs, CTOs, and leading actors in a movie. Some jobs have only the measurement, and it's not enough. For instance, doing piecework in a sweatshop or any manual job you have a measurement but no leverage. To get rich, you have to seek both.
"I think everyone who gets rich by their own efforts will be found to be in a situation with measurement and leverage. Everyone I can think of does: CEOs, movie stars, hedge fund managers, professional athletes."
However, you don't need to become a CEO or a movie star to be in the position of measurement and leverage. You need to be a part of a small group working on difficult problems.
Graham encourages us to start by picking a hard problem and take the difficult path at every point in our decision-making process.
4. How successful startups work.
“You need three things to create a successful startup: to start with good people, to make something customers actually want, and to spend as little money as possible. Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.”
One of the best ways to get rich these days is to make a bet with the world that a given startup will be successful and either start or join a startup at the earliest stage possible. Paul Graham wrote:
“If you wanted to get rich, how would you do it? I think your best bet would be to start or join a startup”
One of the crucial aspects of the startup is the idea behind the company. And a lot of people falsely think that a startup has to have an as innovative idea as it’s even barely impossible to come up with, but as Paul Graham stated it’s quite the opposite. It often has to be just a straightforward idea that is better than what already exists. For example, Google, the guiding light in the world of startups has a simple idea to create a search site that is decent and better than existing solutions.
“They had three new ideas: index more of the Web, use links to rank search results, and have clean, simple web pages with unintrusive keyword-based ads. There were some kind of technical tricks, but overall it was simple idea.”
Another sign of how little the initial idea is worth is the number of startups that change their plan en route, to name a few: IBM, Microsoft, and Twitter was originally meant to be a platform for podcasting. What’s more important than idea is people behind the startup.
Brian Chesky, the co-founder of Airbnb, found that hiring the right people is a crucial factor in a startup's success. Brian hired people himself up to two hundred employees, trying to find out if they fit the company's culture.
“When you start a company, the most important cultural decisions you make are the people you surround yourself with. Hiring is the most important thing to culture because you’re bringing people in and so the culture becomes the people around you.”
About people, Graham added:
“What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.”
Paul Graham said that the essence of startups is growth and everything that comes out of it. Startups are the kind of companies designed to grow rapidly, and they need scale to do so. But to be able to scale, you have to do something that you can sell to a big market. That's the key difference between Microsoft and restaurants, Google, and barbershops. And there are two things we should be focused on to create a successful company:
”For a company to grow really big, it must (a) make something lots of people want, and (b) reach and serve all those people.”
Successful startups can somehow capture the notion of one connection between ideas and technology. Rapid changes in technology can uncover huge and also soluble problems of ideas in other areas. And for grasping that correlation between ideas to solve and rapidly changing technology should strive founders.
Graham said that successful founders can see different problems and invisible patterns. And that was the case for the founders of Google or Steve Wozniak:
Steve Wozniak's problem was that he wanted his own computer. That was an unusual problem to have in 1975. But technological change was about to make it a much more common one. Because he not only wanted a computer but knew how to build them, Wozniak was able to make himself one. And the problem he solved for himself became one that Apple solved for millions of people in the coming years. But by the time it was obvious to ordinary people that this was a big market, Apple was already established.
Successful startups set the directions and seek out new ways of doing things. But it all should take into consideration the crucial aspect, next to the idea and people, which is making a product that customers want. And to know what customers want, Graham gave straightforward advice. Watch them and pay attention to the niche markets.
Additionally, you should aim to make a product easy to use, better than existing technology, and inexpensive. It’s worth mentioning that Stephen Hawking's editor told him that every equation he included in his book would cut sales in half.
“A 10% improvement in ease of use doesn't just increase your sales 10%. It's more likely to double your sales.”
And the best odds are in niche markets. Graham added:
If you build the simple, inexpensive option, you'll not only find it easier to sell at first, but you'll also be in the best position to conquer the rest of the market.
Understanding growth is a crucial part of successful startups. Starting a startup is the commitment you make to solve a harder type of problem than ordinary businesses do. You're committing to search for one of the rare ideas that generate rapid growth.
And it all has to be done in the long-term framework. You have to be persistent because it usually takes longer than you think.
5. How to become a good programmer
“Young programmers are better off not starting with the theoretical foundations of CS, but by eagerly writing crappy programs.“
I'm not an experienced programmer. However, Paul Graham sowed a seed of coding curiosity in me through his famous anthology. And I enjoy coding my side projects, especially when I have to use TypeScript, my favorite programming language. So, I wanted to gather his technical wisdom and draw a couple of conclusions about learning how to code and becoming a good programmer.
1) Find a friend or mentor who can direct you through your coding journey, explaining popular concepts, best practices, and complex issues.
“Finally, find friends who like to write programs. They can answer your technical questions; you'll get new ideas from talking to them; and they'll be the audience for your first efforts. “
2) Hold a program in your head
“A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he's working on“
Paul pointed out the eight steps that allow you to hold your program in your head, make you a better programmer:
Avoid distractions
Work in long stretches
Use succinct languages
Keep rewriting your program
Write rereadable code
Work in small groups
Don't have multiple people editing the same piece of code
Start small
3) Write a lot of (crappy) programs by doing small steps.
“The way to be good at programming is to work (a) a lot (b) on hard problems. And the way to make yourself work on hard problems is to work on some very engaging project.“
4) Learn about specific problems that you finding a way to solve.
“Your code is your understanding of the problem you're exploring. So it's only when you have your code in your head that you really understand the problem.“
5) Modify the code.
“A good way to begin is to take an existing program and modify it to do something new.“
6) Be questionable and seek an innovative way of doing things
“Those in authority tend to be annoyed by hackers’ general attitude of obedience. But that disobedience is a byproduct that make them good programmers“
Programming comes down to practice and solving problems, but the crucial question is what problems to solve. That’s why we see good cohesion between startups and tech. Founders of rapidly growing startups have to constantly working on solving problems and decide what’s the critical problem.
6. Art - learn by doing. Hackers & Painters.
“What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.”
People mistakenly consider hacking as a cold, precise, methodical, and technical-oriented activity that is the complete opposite of painting which is the pure expression of some primal urge. And both images are wrong. They have more in common than it seems.
First and foremost, Hackers and painters are doers. The code can be as beautiful and clean as the color palette. And the painting can be methodical and precise as great lines of code.
In his most famous essay “Hackers and Painters“ and the book named after that essay Graham shared his experience as a painter and draw analogies on a deep level between the programmer and artist.
Co-founder of Y Combinator believes that hackers can learn from painters the art of craft. Because you learn painting mostly by doing it, and the same for hacking. As Graham said:
“Most hackers don't learn to hack by taking college courses in programming. They learn to hack by writing programs of their own at age thirteen.”
Additionally, because painters leave traces of work, you can study and watch them learn by doing. You can look chronologically at the works of a famous painter and see how he was studying and developing ideas. For example, Leonardo da Vinci was working on Mona Lisa in 1503, left it unfinished, and then finished it after almost 16 years.
“If you look at the work of a painter in chronological order, you'll find that each painting builds on things that have been learned in previous ones. When there's something in a painting that works very well, you can usually find version 1 of it in a smaller form in some earlier painting[…] I think most makers work this way.“
Considering how you mostly learn hacking by doing is a sign that hacking differs from the sciences. Scientists learn mostly by doing labs and setting problems, they don’t learn science by doing it.
Another way how doers learn is from examples and having a point of reference. For painters, the museums are the libraries of techniques and the source of inspiration. Hackers, likewise, can learn coding by looking at the source code and studying other programs.
The same way writers learn. Benjamin Franklin learned to write summarizing the points of Joseph Adisson’s and Richard Steele’s essays and try to reproduce them.
“For hundreds of years it has been part of the traditional education of painters to copy the works of the great masters, because copying forces you to look closely at the way a painting is made.“
Another point we can learn from the paintings is how they were created by gradual refinement. Paintings usually start with a sketch and gradually the colors, lights, and details are put in. It’s not an instant process. The same way hacking should work:
“You're better off if you admit this up front, and write programs in a way that allows specifications to change on the fly.“
Both painting and software require fanatical devotion to be beautiful. And relentlessness wins because invisible details become visible, and the effort started to overshadow the rest.
“In hacking, like painting, work comes in cycles. Sometimes you get excited about some new project and you want to work sixteen hours a day on it.“
Graham was growing up believing that there’s no such thing as good taste, and it’s just a matter of personal preference. And like a lot of things we grew up believing turn out to be false. Graham stated that when you’re a doer, just like painters and hackers, taste becomes a practical matter.
This belief that you’re able to do great things is not only right but also useful. It has crucial consequences for young and ambitious people because they started to believe that they can realize their potential.
“The idea that you could make great things was not just a useful illusion. They were actually right. So the most important consequence of realizing there can be good art is that it frees artists to try to make it. To the ambitious kids arriving at art school this year hoping one day to make great things, I say: don't believe it when they tell you this is a naive and outdated ambition. There is such a thing as good art, and if you try to make it, there are people who will notice.“
The last thing is that painting just like most software is intended for a human audience. So hackers, like painters, must have empathy to do great work. You have to be able to see things from the user's point of view.
For more insights like this, I encourage you to follow me on @ Twitter and join our @ Discord community!
Determination is underestimated. Strong will, a great environment with cultivated discipline empower our determination which means that we can directly increase our odds of success.
Working hard is a complex and dynamic system consisting of natural ability, practice, and effort. However, on a deeper level, it comes down to being honest with yourself.
To be wealthy, you have to be in a position of measurement and leverage. The position where it’s easy to measure your performance, and you're capable of making a big effect simply by doing your work.
Growth is the crucial feature of successful startups. Additionally, it’s worth noting that the people behind the idea are far more important than the idea itself.
To become a good programmer, learn how to hold a program in your head and work on that by doing simple steps.
Learn to see things from the user's point of view.
Create & Grow Monthly Newsletter
Sign up with your email address to get food for thoughts full of actionable ideas that help you create and grow.
No politics. No spam. No chaos.
I respect your privacy and time.
Check your e-mail to confirm your subscription and get the weekly newsletter. Check also spam.
Thank you for joining the community! :)
Lessons from The PayPal Mafia: The Power of Being Open-Minded and Contrarian
Republike: decentralized and user-owned social media that improves the way we live and communicate [essay].
Programming Digressions
Essays at the intersection of culture, software, technology, and engineering.
On Paul Graham’s Essays, and of Y Combinator
In literature, the ambition of the novice is to acquire the literary language; the struggle of the adept is to get rid of it ~ George Bernard Shaw
The title is intended to stress the importance of bottom-up programming in Lisp. Instead of just writing your program in Lisp, you can write your own language on Lisp , and write your program in that… Lisp was meant from the start to be an extensible language. The language itself is mostly a collection of Lisp functions, no different from the ones you define yourself…
Sometimes I will stay up in my room for a day trying to get two sentences that will flow, that will just seem as if they were always there. ~ Maya Angelou, in Conversations with Maya Angelou, ed. Jeffrey M. Elliot (Jackson, MS: University Press of Mississippi, 1989), p.59
…The traditional approach is called top-down design: you say “the purpose of the program is to do these seven things, so I divide it into seven major subroutines. The first subroutine has to do these four things, so it in turn will have four of its own subroutines,” and so on. This process continues until the whole program has the right level of granularity—each part large enough to do something substantial, but small enough to be understood as a single unit.
Experienced Lisp programmers divide up their programs differently. As well as top-down design, they follow a principle which could be called bottom-up design—changing the language to suit the problem. In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program. As you’re writing a program you may think “I wish Lisp had such-and-such an operator.” So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together (italics are mine). Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.
If you want to learn about complexity classes, scaling laws in computation, undecidability, randomized algorithms, how to prepare a dinner with Pommard, Quail and Roquefort, or the new ideas that quantum theory brings to computation, this is the right book. It offers a wonderful tour through many facets of computer science. It is precise and gets into details when necessary, but the main thread is always at hand, and entertaining anecdotes help to keep the pace. ~ Marc Mézard, Université de Paris Sud, Orsay
- Y combinator (mathematical function) , one of the most well-known fixed-point combinators in untyped lambda calculus, or to
- Y Combinator (company) , an American company that provides seed money, advice, and person-to-person networking connections in their yearly programs
Writing a book is a horrible, exhausting struggle, like a long bout of some painful illness. One would never undertake such a thing if one were not driven on by some demon whom one can neither resist nor understand. For all one knows that demon is simply the same instinct that makes a baby squall for attention. And yet it is also true that one can write nothing readable unless one constantly struggles to efface one’s own personality. Good prose is like a windowpane. ~ George Orwell, Why I Write (England Your England and Other Essays)
For me, writing is the only thing that passes the three tests of metier: (1) when I’m doing it, I don’t feel that I should be doing something else instead; (2) it produces a sense of accomplishment and, once in a while, pride; and (3) it’s frightening. ~ Gloria Steinem
Share this:
Your comment here cancel reply.
This site uses Akismet to reduce spam. Learn how your comment data is processed .
- Advanced Search
Browse Books
- O'Reilly & Associates, Inc.
- 103A Morris St. Sebastopol, CA
- United States
Save to Binder
"The computer world is like an intellectual Wild West, in which you can shoot anyone you wish with your ideas, if you're willing to risk the consequences. " --from Hackers & Painters: Big Ideas from the Computer Age, by Paul Graham We are living in the computer age, in a world increasingly designed and engineered by computer programmers and software designers, by people who call themselves hackers. Who are these people, what motivates them, and why should you care? Consider these facts: Everything around us is turning into computers. Your typewriter is gone, replaced by a computer. Your phone has turned into a computer. So has your camera. Soon your TV will. Your car was not only designed on computers, but has more processing power in it than a room-sized mainframe did in 1970. Letters, encyclopedias, newspapers, and even your local store are being replaced by the Internet. Hackers & Painters: Big Ideas from the Computer Age, by Paul Graham, explains this world and the motivations of the people who occupy it. In clear, thoughtful prose that draws on illuminating historical examples, Graham takes readers on an unflinching exploration into what he calls "an intellectual Wild West." The ideas discussed in this book will have a powerful and lasting impact on how we think, how we work, how we develop technology, and how we live. Topics include the importance of beauty in software design, how to make wealth, heresy and free speech, the programming language renaissance, the open-source movement, digital design, internet startups, and more. And here's a taste of what you'll find in Hackers & Painters: "In most fields the great work is done early on. The paintings made between 1430 and 1500 are still unsurpassed. Shakespeare appeared just as professional theater was being born, and pushed the medium so far that every playwright since has had to live in his shadow. Albrecht Durer did the same thing with engraving, and Jane Austen with the novel. Over and over we see the same pattern. A new medium appears, and people are so excited about it that they explore most of its possibilities in the first couple generations. Hacking seems to be in this phase now. Painting was not, in Leonardo's time, as cool as his work helped make it. How cool hacking turns out to be will depend on what we can do with this new medium." Andy Hertzfeld, co-creator of the Macintosh computer, says about Hackers & Painters: "Paul Graham is a hacker, painter and a terrific writer. His lucid, humorous prose is brimming with contrarian insight and practical wisdom on writing great code at the intersection of art, science and commerce." Paul Graham, designer of the new Arc language, was the creator of Yahoo Store, the first web-based application. In addition to his PhD in Computer Science from Harvard, Graham also studied painting at the Rhode Island School of Design and the Accademia di Belle Arti in Florence.
- Publication Years 1988 - 2021
- Publication counts 48
- Citation count 204
- Available for Download 7
- Downloads (cumulative) 2,424
- Downloads (12 months) 158
- Downloads (6 weeks) 19
- Average Downloads per Article 346
- Average Citation per Article 4
Index Terms
Hackers and painters: essays on the art of programming.
Social and professional topics
Computing / technology policy
Intellectual property
Professional topics
Computing industry
Computing profession
Computing occupations
Management of computing and information systems
Project and people management
Project staffing
Systems development
Software and its engineering
Software notations and tools
General programming languages
Language types
Functional languages
Reviewer: Diomidis Spinellis
Graham has a Ph.D. in Computer Science from Harvard University, and has also studied painting at the Rhode Island School of Design (RISD) and the Accademia in Florence. His background reveals itself both in the title of his book, and in the contents of its 15 separate essays. Their subjects vary; an overarching description of the work could well be an ode to freedom: freedom to be unpopular in school, freedom to write programs by hacking, freedom to break the rules, freedom to think heretical thoughts, freedom to create (and keep) wealth, freedom from spam, and freedom to program the task at hand in the most expressive programming language. Don't look for a balanced treatment of ideas in these essays. Graham knows exactly where he stands on many different issues: server-based software is the future of computing; unequal income distribution is a sign of a healthy society; Bayesian techniques are an effective method for fighting spam; and languages supporting dynamic typing, and Lisp in particular, are tremendous boosters of programmer productivity. He expresses his thought provoking and often contrarian ideas in no uncertain terms, with eloquence, convincing arguments, and entertaining examples. In the essays, there is a nugget of wisdom for (almost) everyone: for the budding computer hacker who wonders which language to learn, the parents whose bright kid is harassed at school, the megacorp's CEO rethinking the company's hiring practices and compensation plan, the startup founder who wants to take megacorp's business, and the politician who wants to encourage both companies to invest in her or his country. People involved in information technology, either from a technical or from a business perspective, will certainly enjoy reading, and benefit from, this book. The book could also be used as background reading material in graduate courses on technology policy; it would certainly spark many lively discussions in class. While one may not agree with all of the ideas put forward in the book, one has to admit that putting them on paper takes courage, and provides a valuable service to our community. And we have to thank Graham for that. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Export Citations
- Preview is not available. By clicking download, a new tab will open to start the export process. The process may take a few minutes but once it finishes a file will be downloaded on your browser so please do not close the new tab. Download
- Download citation
- Copy citation
We use cookies to ensure that we give you the best experience on our website.
Finding all of Paul Graham's essays in an epub/pdf?
Hi! I've recently read his 'Do Things That Don't Scale' essay, and found it incredible and full of practical advices. Any place to find an epub/pdf so that I can read it on my phone while on the go? Thanks!
I did that recently i'll upload it for you :) my case was - i wanted to print them all for my collection and to ease it on my eyes.
doc file https://www.dropbox.com/s/e2xueytqm38a0sj/y-comb-list.docx?dl=0
https://www.dropbox.com/s/r7eu89rkz3caz00/y-comb-list.htm?dl=0
This is perfect! Are these all his essays? Because 'Do things that don't scale' is at the top of your document, yet it's not the newest/oldest essay AFAIK
Thank you for sharing :)
Or use Pocket (or something similar) - you can download articles for offline reading - I find it indispensable. Comes with a chrome extension too, well recommended :)
Btw PG rules
Well, its mostly his old essays, but theres this: https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554
I wrote a python scraper, it's in pdf but the formatting is not so great.
https://github.com/Imran31/Essay_Scraper
Run and done
Short of previously published PDFs, you can 1) save each essay to Pocket for nicely formatted offline reading or 2) clip each essay to Evernote, also for easy offline reading.
About Community
Reading 05: Programming Languages
The readings for this week are:
Beating the Averages
The Hundred-Year Language
Revenge of the Nerds
Reflections
In these essays, Paul Graham discusses the power of programming languages such as Lisp and how this non-conventional language proved to be a competitive advantage in creating Viaweb :
Our secret weapon, Lisp , was similar. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses. For years it had annoyed me to hear Lisp described that way. But now it worked to our advantage. In business, there is nothing more valuable than a technical advantage your competitors don't understand. In business, as in war, surprise is worth as much as force.
For this upcoming week, you are to consider the following questions as you perform the readings and participate in class:
Discuss the idea behind the statement: "programming languages are not just technology, but what programmers think in." How does a programming language impact the way you tackle a problem or construct an application?
Discuss whether or not "programming languages vary in power." Are some languages intrinsically more powerful than other languages? What makes one language better than another?
Discuss your experiences with alternative languages such as Lisp , Scheme , Erlang , Haskell or any non-conventional language. What drew you to these languages? Did you find them to be useful? Do you still use them? Explain why or why not.
Note, you should not simply list the questions and answer each one directly. Instead, the questions are there to help you brainstorm about the question:
How important is the choice of programming language in software development and computer science? What is lacking in our current set of tools? What ideas or features will continue to persist far into the future?
Some food for thought:
What makes Paul Graham a great writer?
In the last few months, I’ve heard these 4 statements from 4 different people:
“I wish I could write like Paul Graham.”
“If I had to pick one writer to imitate, it would be Paul Graham.”
“Paul Graham’s writing is the epitome of clarity.”
“Paul Graham inspired me to start writing.”
This widespread sentiment motivated me to dive deeper into Graham’s writing, with help from my collaborator & writing mentor Dr. William Jaworski . What’s Paul Graham doing that’s so special? In the world of writing, what do his fingerprints look like?
Here’s what we’ve observed.
He organizes each essay around a razor-sharp core idea.
All imagery in this blog post comes from the 1930 film The Blood of a Poet.
Every essay needs a core idea. Maybe you think of it as the focal point, the thesis, or the argument you’re making. Dr. Jaworski frames it as “a pithy one-liner that serves as an organizing principle for the whole essay.”
When you’re in tune with a core idea, writing feels easier. Intrusive thoughts soften and recede. You’re able to slow down and think more systematically. You start to see where your essay will end (and where a different one might begin—another day). You have a bullseye in your sights.
Usually, you can grasp the core idea of a Paul Graham essay by reading the title. My favorite examples are The Two Kinds of Moderate , The Bus Ticket Theory of Genius , and Write Like You Talk . As you read any of those, you’ll see how every paragraph, and in fact every sentence, connects with the core idea. His focus is sharp and unwavering.
Admire that commitment & focus, but realize that even for Graham, essay ideas aren’t sharp from the get-go. Don’t let hazy vision dissuade you: a blurry bullseye is better than no bullseye. The important thing is to not give up—and also to avoid falling in love with any particular idea.
…which brings me to a new point about Paul Graham’s writing!
He doesn’t fall in love with his ideas.
From experience, Paul Graham knows even smart people have bad ideas. That’s why it’s important not to get caught up in your own. Some of your ideas will be good; some won’t. That’s fine. In fact, it’s completely inevitable: if you want to have good ideas, you have to accept the reality of having bad ones.
In How to Write Usefully , Paul Graham states this principle about as point-blank as it gets:
If you write a bad sentence, you don’t publish it. You delete it and try again. Often you abandon whole branches of four or five paragraphs. Sometimes a whole essay. You can’t ensure that every idea you have is good, but you can ensure that every one you publish is, by simply not publishing the ones that aren’t.
Graham’s essay Startups in 13 Sentences is a subtler illustration of the same idea. There’s no fancy technical footwork—structurally, it’s a plain-Jane listicle. Yet, there’s real insight in it. There’s the feeling that these ideas have weight and presence. That’s because those 13 ideas have been curated from a wide range of options. The essay is not the product of 13 ideas; it’s the product of 1,000+ ideas, narrowed down to 13. Before that essay ever saw the light of day, Paul Graham sifted through many good, bad, and half-decent ideas, and selected the best.
When Paul Graham starts thinking, he often finds dead ends. He explores the twists & turns his thoughts can take, and eventually he finds the path down which he most wants to guide his readers. Choosing that path to the exclusion of the others requires being a ruthless self-editor—someone who can step back & observe his own writing from a healthy distance. This process is the mark of a good thinker, and it’s also a mark of a good writer.
He couples concepts with concrete examples.
About 70% of Paul Graham’s essays contain the word “example,” usually within the phrase “for example.” When he introduces an abstract idea, you’re never more than a sentence or two away from a well-picked example.
For example, in Copy What You Like , Graham writes, “ It’s easy to be drawn into imitating flaws, because they’re easier to see, and of course easier to copy too.”
On its own, that sentence isn’t too useful. But immediately, Graham supplies a real example:
For example, most painters in the eighteenth and nineteenth centuries used brownish colors. They were imitating the great painters of the Renaissance, whose paintings by that time were brown with dirt. Those paintings have since been cleaned, revealing brilliant colors; their imitators are of course still brown.
Thanks to that follow-up, I have a better sense of what Graham means.
Graham uses lots of examples because he knows concepts are tools used for thinking about the world. But a tool is helpful only if you know how to use it, and you learn how to use a concept by applying it to real things.
Paul Graham’s examples show you how to apply concepts to real life. Applying unfamiliar concepts to familiar examples makes those concepts easier to master.
Here are three more short meta-examples:
From Being a Noob :
The more of a noob you are locally, the less of a noob you are globally. For example , if you stay in your home country, you’ll feel less of a noob than if you move to Farawavia, where everything works differently. And yet you’ll know more if you move.
From Stuff :
Nothing owns you like fragile stuff. For example, the “good china” so many households have, and whose defining quality is not so much that it’s fun to use, but that one must be especially careful not to break it.
From What Doesn’t Seem Like Work :
If something that seems like work to other people doesn’t seem like work to you, that’s something you’re well suited for. For example, a lot of programmers I know, including me, actually like debugging. It’s not something people tend to volunteer; one likes it the way one likes popping zits. But you may have to like debugging to like programming, considering the degree to which programming consists of it.
He creates rhythm by varying sentence length.
When people talk about a writer’s “voice,” they’re largely talking about the rhythm of the writing. Is it choppy? Is it droning? Does it feel conversational? Much of this comes down to the lengths of your sentences, and especially how you mix and match them.
Paul Graham rarely uses long sentences, but he mixes and matches short and medium-length sentences to create a rhythm that mirrors the pace of real conversation.
A well-placed short sentence creates a pause. The key expression here is well-placed : you wouldn’t want to listen to a speaker who follows every sentence with a dramatic pause. Paul Graham tends to taper the lengths of his sentences down until he reaches a key point—something he wants to emphasize. That’s where he pauses.
Here’s a perfect example from Life is Short . Notice how Paul Graham uses the two shortest sentences in the paragraph (bolded), nestled among longer ones, to create points of salience.
If life is short, we should expect its shortness to take us by surprise. And that is just what tends to happen. You take things for granted, and then they’re gone. You think you can always write that book, or climb that mountain, or whatever, and then you realize the window has closed. The saddest windows close when other people die. Their lives are short too. After my mother died, I wished I’d spent more time with her. I lived as if she’d always be there. And in her typical quiet way she encouraged that illusion. But an illusion it was. I think a lot of people make the same mistake I did.
During our review of Paul Graham’s writing, Dr. Jaworski identified this technique and explained it to me. As part of his explanation, he wrote this awesome paragraph that I can’t help but share:
“Imagine you and I are taking a leisurely stroll, conversing as we go—the pace of our words matching the pace of our strides. Then something happens. There’s something I want to say, but I have trouble saying it. It’s important. We slow down. We stop. I struggle to find the words. I utter them. One. By. One. For emphasis. See? I’m being waggish, of course, but I trust you see the point: when you want to emphasize something, you need to slow the reader’s pace with shorter sentences and bolder punctuation. Conversely, when you’ve covered what’s important, you need to regain momentum using longer sentences and lighter punctuation, and might even forgo full stops entirely in favor of commas, conjunctions, semi-colons, dashes, and other devices that keep the reader moving.”
For me, Dr. Jaworski’s illustration is the most intuitive way to understand this technique. Of course, that doesn’t mean I’ll master it overnight—it takes practice and patience. But now, I have an effective metaphor to guide me.
He doesn’t underestimate your intelligence.
Yes, Paul Graham prefers short sentences and short words—his essays pass the Hemingway test with flying colors. But that doesn’t mean he’s dumbing his writing down. Quite the opposite: Graham knows he’s talking about sophisticated ideas, so he presents them cleanly, getting his writing out of the way. He avoids over-explaining things, which is a great way to evade rabbit holes.
Basically, he knows how to put himself in a smart reader’s shoes, and as soon as he starts thinking, “Yep, I get it”—he stops.
He’s codified his own rules, and he follows them.
In 2005, Paul Graham codified his own rules for writing, and they’re exquisite. Get this: on my team of experienced writers, none of us had seen Graham’s rules before—but in our own separate ways, we’d each already learned to follow them.
So, straight from the horse’s mouth, here they are:
Write a bad version 1 as fast as you can; rewrite it over and over.
cut out everything unnecessary.
write in a conversational tone.
develop a nose for bad writing, so you can see and fix it in yours.
imitate writers you like.
if you can’t get started, tell someone what you plan to write about, then write down what you said.
expect 80% of the ideas in an essay to happen after you start writing it, and 50% of those you start with to be wrong.
be confident enough to cut.
have friends you trust read your stuff and tell you which bits are confusing or drag.
don’t (always) make detailed outlines.
mull ideas over for a few days before writing.
carry a small notebook or scrap paper with you.
start writing when you think of the first sentence; if a deadline forces you to start before that, just say the most important sentence first.
write about stuff you like.
don’t try to sound impressive.
don’t hesitate to change the topic on the fly.
use footnotes to contain digressions.
use anaphora to knit sentences together.
read your essays out loud to see (a) where you stumble over awkward phrases and (b) which bits are boring (the paragraphs you dread reading).
try to tell the reader something new and useful.
work in fairly big quanta of time.
when you restart, begin by rereading what you have so far.
when you finish, leave yourself something easy to start with.
accumulate notes for topics you plan to cover at the bottom of the file; don’t feel obliged to cover any of them.
write for a reader who won’t read the essay as carefully as you do, just as pop songs are designed to sound ok on crappy car radios.
if you say anything mistaken, fix it immediately.
ask friends which sentence you’ll regret most.
go back and tone down harsh remarks.
publish stuff online, because an audience makes you write more, and thus generate more ideas.
print out drafts instead of just looking at them on the screen.
use simple, germanic words.
learn to distinguish surprises from digressions.
learn to recognize the approach of an ending, and when one appears, grab it.
Room for improvement?
It’s hard to criticize Paul Graham as a writer. Actually, it feels heretical, which is why I think it’s important to do it.
I want to point out one thing that might stand between Paul Graham and an undying legacy as a great writer (if that’s a legacy he wants). That thing is risk aversion.
Paul Graham has refined his skill as an essayist to a point nearing perfection. But the peak he’s reached as an essayist might be a plateau in his overall development as a writer. It’s been a long time since Graham tried something new in his published writing.
In both of his latest pieces, Orthodox Privilege and The Four Quadrants of Conformism , I see an outstanding communicator whose surgical competence might be interfering with his intuition. Don’t get me wrong: both essays are superb. In a sense, they’re flawless—almost the way auto-tuned music is flawless. There’s no imperfection, and that, in itself, might be a flaw.
What could Paul Graham do if he took more risks as a writer? I don’t know. He’s the creator; I’m just part of the peanut gallery. But given his great talent & skill, I hope he explores the possibilities.
I’m happily indebted to both Dr. Jaworski and Pavel Brodsky for their essential contributions to this essay.
This essay is the first in a series. Want the next one in your inbox? Sign up below!
Dabblers And Blowhards
I actually worry a lot that as I get "popular" I'll be able to get away with saying stupider stuff than I would have dared say before. This sort of thing happens to a lot of people, and I would *really* like to avoid it - Paul Graham, posting on lemonodor.com
About two years ago, the Lisp programmer and dot-com millionaire Paul Graham wrote an essay entitled Hackers and Painters , in which he argues that his approach to computer programming is better described by analogies to the visual arts than by the phrase "computer science".
When this essay came out, I was working as a computer programmer, and since I had also spent a few years as a full-time oil painter , everybody who read the article and knew me sent along the hyperlink. I didn't particularly enjoy the essay — I thought the overall tone was glib, and I found the parallel to painting unconvincing — but it didn't seem like anything worth getting worked up about. Just another programmer writing about what made him tick.
But the emailed links continued, and over the next two years Paul Graham steadily ramped up his output while moving definitively away from subjects he had expertise in (like Lisp) to topics like education, essay writing, history, and of course painting. Sometime last year I noticed he had started making bank from an actual print book of collected essays, titled (of course) "Hackers and Painters". I felt it was time for me to step up.
So let me say it simply - hackers are nothing like painters.
It's surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. In his essays he tends to flit from metaphor to metaphor like a butterfly, never pausing long enough to for a suspicious reader to catch up with his chloroform jar. The closest he comes to a clear thesis statement is at the beginning "Hackers and Painters":
"[O]f all the different types of people I've known, hackers and painters are among the most alike. What hackers and painters have in common is that they're both makers."
To which I'd add, what hackers and painters don't have in common is everything else. The fatuousness of the parallel becomes obvious if you think for five seconds about what computer programmers and painters actually do.
- Computer programmers cause a machine to perform a sequence of transformations on electronically stored data.
- Painters apply colored goo to cloth using animal hairs tied to a stick.
It is true that both painters and programmers make things, just like a pastry chef makes a wedding cake, or a chicken makes an egg. But nothing about what they make, the purposes it serves, or how they go about doing it is in any way similar.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task. Even the most elegant of computer programs, in order to be considered a program, has to compile and run [ 1 ]. So just like mechanical engineers and architects, computer programmers create artifacts that have to stand up to an objective reality. No one cares how pretty the code is if the program won't work.
The only objective constraint a painter has is making sure the paint physically stays on the canvas (something that has proven surprisingly challenging ). Everything beyond that is aesthetics - arranging colored blobs in a way that best tickles the mind of the viewer.
This difference is what makes programming so similar to engineering, which also tries to create beautiful things in the face of objective constraints, but it's a parallel that really rankles Graham. He interprets it as implying that there should be limits on the creative control programmers exercise over their work: [ 2 ]
Doug Kaye : In what ways do you think to program is more like painting than it is like some of our more common metaphors such as engineering? Paul Graham : [...] in buildings, for example there is this distinction between architects and engineers. Architects decide what the building is going to look like basically and then they say to an engineer, "Can I do this? And then how?" And the engineer figures out how. So architects figure out "what," engineers figure out "how." Well painters do both. Painters decide what to paint and then have to paint it. And hackers in the best case also do both[ 3 ].
You can safely replace "painters" in this response with "poets", "composers", "pastry chefs" or "auto mechanics" with no loss of meaning or insight. There's nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like to feel that his programming allows him a similar level of self-expression. The reason Graham's essay isn't entitled "Hackers and Pastry Chefs" is not because there is something that unites painters and programmers into a secret brotherhood, but because Paul Graham likes to cultivate the arty aura that comes from working in the visual arts. Having been both a painter and a programmer, I can certainly sympathize with him.
Great paintings, for example, get you laid in a way that great computer programs never do. Even not-so-great paintings - in fact, any slapdash attempt at splashing paint onto a surface - will get you laid more than writing software, especially if you have the slightest hint of being a tortured, brooding soul about you. For evidence of this I would point to my college classmate Henning, who was a Swedish double art/theatre major and on most days could barely walk.
Also remark that in painting, many of the women whose pants you are trying to get into aren't even wearing pants to begin with. Your job as a painter consists of staring at naked women, for as long as you wish, and this day in and day out through the course of a many-decades-long career. Not even rock musicians have been as successful in reducing the process to its fundamental, exhilirating essence.
It's no surprise, then, that a computer programmer would want to bask in some of the peripheral coolness that comes with painting, especially when he has an axe to grind about his own work being 'mere engineering'. Yet while this might be charming or quirky in the abstract, it gets seriously annoying when real facts start getting butchered:
""When oil paint replaced tempera in the fifteenth century, it helped painters to deal with difficult subjects like the human figure because, unlike tempera, oil can be blended and overpainted." [ 4 ] "The paintings made between 1430 and 1500 are still unsurpassed." "Compositional symmetry yields some of the most memorable paintings" " It is not merely an accident of history that the great paintings of the Renaissance are all full of people. If they hadn't been, painting as a medium wouldn't have the prestige that it does." "Worse is Better is found throughout the arts. In drawing, for example, the idea was discovered during the Renaissance." "What made oil paint so exciting, when it first became popular in the fifteenth century, was that you could actually make the finished work from the prototype." "Most painters start with a blurry sketch and gradually refine it." "Line drawings are in fact the most difficult visual medium [ 5 ]" " The point of painting from life is that it gives your mind something to chew on: when your eyes are looking at something, your hand will do more interesting work." "Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry. You need to know how to calculate time and space complexity and about Turing completeness. You might also want to remember at least the concept of a state machine, in case you have to write a parser or a regular expression library. Painters in fact have to remember a good deal more about paint chemistry than that." [ 6 ]
All of these statements are wrong, or dumb, or both, and yet they are sprinkled through various essays like raisins in a fruitcake, with no further justification, and the reader is expected to enjoy the chewy burst of flavor and move on to the next tidbit.
I am not qualified to call bullshit on Paul Graham when he writes about programming, history, starting a business, or even growing up as a social pariah, but I do know enough about art to see when someone is just making shit up.
In Paul Graham's world, as soon as oil paint was invented, painting techniques made a discontinuous jump from the fifteenth to the twentienth century, fortuitously allowing Renaissance painters to paint a lot like Paul Graham. And the difficult problems the new medium supposedly helped painters solve just happened to resemble the painting problems that confront an enthusiastic but not particularly talented art student. I hope I am not the only to find this highly suspicious.
I blame Eric Raymond and to a lesser extent Dave Winer for bringing this kind of schlock writing onto the Internet. Raymond is the original perpetrator of the " what is a hacker? " essay, in which you quickly begin to understand that a hacker is someone who resembles Eric Raymond. Dave Winer has recently and mercifully moved his essays off to audio, but you can still hear him snorfling cashew nuts and talking at length about what it means to be a blogger[ 7 ] . These essays and this writing style are tempting to people outside the subculture at hand because of their engaging personal tone and idiosyncratic, insider's view. But after a while, you begin to notice that all the essays are an elaborate set of mirrors set up to reflect different facets of the author, in a big distributed act of participatory narcissism.
The whole genre reminds me of the the wooly business books one comes across at airports ("Management secrets of Gengis Khan", the "Lexus and the Olive Tree") that milk a bad analogy for two hundred pages to arrive at the conclusion that people just like the author are pretty great.
Any of these books will give you more in a page than Paul Graham can offer across the whole broad and aggressively expanding corpus of his online essays, and none of them will leave you with that dissatisfied, preached-at-in-the-corner-by-your-uncle feeling that has become a hallmark of Graham's less technical writing.
As for the mystical connection between painters and programmers, the famous Lloyd Bentsen put-down keeps coming to mind. Unless you are actually making art with computers - something that can be perfectly wonderful - being a hobbyist programmer is not going to let you in to art club. You can look up to the guys who made the Boeing 747, the original Macintosh, the Verazzano Narrows bridge, and other beautiful artifacts of engineering and design. And you can aspire to walk in the footsteps of Faraday, Edison, Telford, Benjamin Franklin, and any other number of inspired tinkerers and builders.
But you, sir, are no painter. And while you hack away at your terminal, or ride your homemade Segway, we painters and musicians are going to be right over here with all the wine, hash, and hot chicks.
[ 1 ] Some Arc hackers may disagree with this.
[ 2 ] Paul Graham is a weenis.
[ 3 ] Yes, these notes are a parody .
[ 4 ] It's hard to understand how fatuous this statement is unless you've tried your hand at painting, which is one reason Graham gets away with this stuff. The allusion here is to a sketchy, iterative style of painting that used to be called "alla prima", where you block shapes in in oil paint and then swoosh them around the composition as the painting progresses, perhaps repainting entire sections of the picture. This is the way Graham and I were taught to paint, but it has nothing whatsoever to do with painting in the fifteenth century, where you had a superprecise underdrawing and underpainting that were covered with thin glazes of color.
And it has equally little do with the difficulty of your subject matter. Being able to blend and overpaint has as much to do with being a skilled draughtsman as having an eraser on your pencil has to do with being a good writer.
The Greeks did pretty well with the human form despite having to work in stone.
[ 5 ] Dipshit.
[ 6 ] All painters really have to remember about chemistry is fat over lean and don't ash in the turpentine.
[ 7 ] Winer, at least, has yet to publish a HOWTO on proper oral sex technique , but if he ever touches a woman I expect the worst.
Frequent Topics
Greatest Hits
Every Damn Thing
Maciej Cegłowski maciej @ ceglowski.com
Please ask permission before reprinting full-text posts or I will crush you.
- No suggested jump to results
- Notifications
AI search & chat for all of Paul Graham’s essays.
mckaywrigley/paul-graham-gpt
Name already in use.
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more .
- Open with GitHub Desktop
- Download ZIP
Sign In Required
Please sign in to use Codespaces.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Latest commit
Paul Graham GPT
AI-powered search and chat for Paul Graham's essays .
All code & data used is 100% open-source.
The dataset is a CSV file containing all text & embeddings used.
Download it here .
I recommend getting familiar with fetching, cleaning, and storing data as outlined in the scraping and embedding scripts below, but feel free to skip those steps and just use the dataset.
How It Works
Paul Graham GPT provides 2 things:
- A search interface.
- A chat interface.
Search was created with OpenAI Embeddings ( text-embedding-ada-002 ).
First, we loop over the essays and generate embeddings for each chunk of text.
Then in the app we take the user's search query, generate an embedding, and use the result to find the most similar passages from the book.
The comparison is done using cosine similarity across our database of vectors.
Our database is a Postgres database with the pgvector extension hosted on Supabase .
Results are ranked by similarity score and returned to the user.
Chat builds on top of search. It uses search results to create a prompt that is fed into GPT-3.5-turbo.
This allows for a chat-like experience where the user can ask questions about the book and get answers.
Running Locally
Here's a quick overview of how to run it locally.
Requirements
- Set up OpenAI
You'll need an OpenAI API key to generate embeddings.
- Set up Supabase and create a database
Note: You don't have to use Supabase. Use whatever method you prefer to store your data. But I like Supabase and think it's easy to use.
There is a schema.sql file in the root of the repo that you can use to set up the database.
Run that in the SQL editor in Supabase as directed.
I recommend turning on Row Level Security and setting up a service role to use with the app.
- Install dependencies
- Set up environment variables
Create a .env.local file in the root of the repo with the following variables:
- Run scraping script
This scrapes all of the essays from Paul Graham's website and saves them to a json file.
- Run embedding script
This reads the json file, generates embeddings for each chunk of text, and saves the results to your database.
There is a 200ms delay between each request to avoid rate limiting.
This process will take 20-30 minutes.
Thanks to Paul Graham for his writing.
I highly recommend you read his essays.
3 years ago they convinced me to learn to code, and it changed my life.
If you have any questions, feel free to reach out to me on Twitter !
I sacrificed composability for simplicity in the app.
Yes, you can make things more modular and reusable.
But I kept pretty much everything in the homepage component for the sake of simplicity.
- TypeScript 94.1%
- PLpgSQL 3.8%
- JavaScript 1.4%
Paul Graham (programmer)
Paul Graham ( / ɡ r æ m / ; born 13 November 1964) [1] is an English born computer scientist , entrepreneur , venture capitalist , author, and blogger . He is best known for his work on Lisp , his former startup Viaweb (later renamed "Yahoo! Store"), co-founding the influential startup accelerator and seed capital firm Y Combinator , his blog, and Hacker News . He is the author of several programming books, such as: On Lisp [3] (1993), ANSI Common Lisp [4] (1995), and Hackers & Painters [5] (2004). Technology journalist Steven Levy has described Graham as a 'hacker philosopher'. [6]
- 1.1 Education
- 2.1 Graham's hierarchy of disagreement
- 2.2 The Blub paradox
- 4 References
- 5 External links
In 1996, Graham and Robert Morris founded Viaweb , the first application service provider (ASP). Viaweb's software, originally written mostly in Common Lisp , allowed users to make their own Internet stores . In the summer of 1998 Viaweb was sold to Yahoo! for 455,000 shares of Yahoo! stock, valued at $49.6 million. [7] At Yahoo! the product became Yahoo! Store .
He later gained fame for his essays on his popular website paulgraham.com. Essay subjects range from "Beating the Averages", [8] which compares Lisp to other programming languages and introduced the hypothetical programming language Blub , to "Why Nerds are Unpopular", [9] a discussion of nerd life in high school. A collection of his essays has been published as Hackers & Painters [5] by O'Reilly , which includes a discussion of the growth of Viaweb and what Graham perceives to be the advantages of Lisp to program it.
In 2001, Graham announced that he was working on a new dialect of Lisp named Arc . Over the years since, he has written several essays describing features or goals of the language, and some internal projects at Y Combinator have been written in Arc, most notably the Hacker News web forum and news aggregator program.
In 2005, after giving a talk at the Harvard Computer Society later published as "How to Start a Startup", Graham along with Trevor Blackwell , Jessica Livingston and Robert Morris started Y Combinator to provide seed funding to a large number of startups , particularly those started by younger, more technically oriented founders. Y Combinator has now invested in more than 1300 startups, including Justin.tv , Xobni , Dropbox , Airbnb and Stripe . [10]
In response to the proposed Stop Online Piracy Act (SOPA), Graham announced in late 2011 that no representatives of any company supporting it would be invited to Y Combinator's Demo Day events. [11]
BusinessWeek included Paul Graham in 2008 edition of its annual feature, The 25 Most Influential People on the Web . [12]
In 2008, Paul Graham married Jessica Livingston . [13] [14] [15]
Graham has a Bachelor of Arts in philosophy from Cornell University [16] [17] (1986). [18] He then attended Harvard University , earning Master of Science (1988) and Doctor of Philosophy (1990) degrees in Computer Science . [16] [19] He has also studied painting at the Rhode Island School of Design and at the Accademia di Belle Arti in Florence . [16] [19]
Graham's hierarchy of disagreement
Graham proposed a "disagreement hierarchy" in a 2008 essay "How to Disagree", [20] putting types of argument into a seven-point hierarchy and observing that "If moving up the disagreement hierarchy makes people less mean, that will make most of them happier." Graham also suggested that the hierarchy can be thought as a pyramid, as the highest forms of disagreement are rarer.
Following this hierarchy, Graham notes that articulate forms of name-calling (e.g. "The author is a self-important dilettante") are no different from crude insults.
The hierarchy resembles Friedrich Glasl's model of conflict escalation [ further explanation needed ] .
The Blub paradox
Graham considers the hierarchy of programming languages with the example of "Blub", a hypothetically average language "right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language ." [21] It was used by Graham to illustrate a comparison, beyond Turing completeness , of programming language power, and more specifically to illustrate the difficulty of comparing a programming language one knows to one that one does not. [22]
Graham considers a hypothetical Blub programmer. When the programmer looks down the "power continuum", he considers the lower languages to be less powerful because they miss some feature that a Blub programmer is used to. But when he looks up, he fails to realise that he is looking up: he merely sees "weird languages" with unnecessary features and assumes they are equivalent in power, but with "other hairy stuff thrown in as well". When Graham considers the point of view of a programmer using a language higher than Blub, he describes that programmer as looking down on Blub and noting its "missing" features from the point of view of the higher language. [22]
Graham describes this as the "Blub paradox" and concludes that "By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one." [22]
The concept has been cited [ why? ] by writers such as Joel Spolsky . [23]
- Anaphoric macro – first appeared in Paul Graham's On Lisp
- ↑ 1.0 1.1 "Graham, Paul 1964- Authorities & Vocabularies (Library of Congress Name Authority File)" . U.S. Library of Congress. 11 March 2005 . Retrieved 12 March 2012 . (Paul Graham, b. Nov. 13, 1964) <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "No; I was born in Weymouth, England. My father's Welsh though. | Hacker News" . News.ycombinator.com . Retrieved 23 January 2013 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Graham, Paul (1994). On Lisp: advanced techniques for Common Lisp . Englewood Cliffs, N.J: Prentice Hall. ISBN 0-13-030552-9 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Graham, Paul (1996). ANSI Common Lisp . Englewood Cliffs, N.J: Prentice Hall. ISBN 0-13-370875-6 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ 5.0 5.1 Graham, Paul (2004). Hackers & painters: big ideas from the computer age . Sebastopol, CA: O'Reilly. ISBN 0-596-00662-4 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Y Combinator Has Gone Supernova https://www.wired.com/story/y-combinator-has-gone-supernova/
- ↑ "Yahoo! to Acquire Viaweb" . Yahoo! Inc. 8 June 1998. Archived from the original on 1 July 2007 . Retrieved 14 April 2008 . Unknown parameter |deadurl= ignored ( help ) <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "Beating the Averages" . paulgraham.com . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "Why Nerds are Unpopular" . paulgraham.com . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "Y Combinator Companies - Y Combinator Universe" . Retrieved 13 March 2013 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Tsotsis, Alexia (22 December 2011). "Paul Graham: SOPA Supporting Companies No Longer Allowed At YC Demo Day" . TechCrunch . Retrieved 23 December 2011 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "The Papa Bear: Paul Graham" . BusinessWeek . 29 September 2008 . Retrieved 29 September 2008 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "Where are we going?" . arclanguage.org. 26 October 2008 . Retrieved 14 November 2008 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ "Congrats to PG on getting hitched" . news.ycombinator.com. 2 June 2008 . Retrieved 14 November 2008 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Graham, Paul (January 2009). "California Year-Round" . Y Combinator . Archived from the original on 13 March 2012. Jessica Livingston and I (who are married despite our different last names) are expecting our first child any day now. Unknown parameter |deadurl= ignored ( help ) <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ 16.0 16.1 16.2 "Paul Graham biography" . PaulGraham.com . Retrieved 22 July 2011 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Undergraduation . Paul Graham . Retrieved 22 July 2011.
- ↑ EZRA: Cornell's Quarterly Magazine (Fall 2011) "Paul Graham '86"
- ↑ 19.0 19.1 "Paul Graham biography" . SpeakerMix.com. Archived from the original on 9 April 2012 . Retrieved 6 March 2012 . Unknown parameter |deadurl= ignored ( help ) <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Graham, Paul (March 2008). "How to Disagree" . PaulGraham.com . Retrieved 2 May 2011 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- ↑ Paul Graham (2001). " Beating the Averages " . Retrieved 28 April 2007 . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>; published in Hackers & Painters , 2004; the essay was also reprinted in The Planning and Scheduling Working Group Report on Programming Languages Archived 16 June 2011 at the Wayback Machine , by JM Adams, R Hawkins, C Myers, C Sontag, S Speck
- ↑ 22.0 22.1 22.2 "...These studies would like to formally prove that a certain language is more or less expressive than another language. Determining such a relation between languages objectively rather than subjectively seems to be somewhat problematic, a phenomenon that Paul Graham has discussed in “The Blub Paradox” [6]." "An Introduction to Aspect Oriented Programming in e" , D. Robinson; see also "Expressive power of recursion and aggregates in XQuery" , by J Hidders, J Paredaens, R Vercammen, S Marrara
- ↑ See "The Perils of JavaSchools" , in his book More Joel on Software .
External links
- No URL found. Please specify a URL here or add one to Wikidata.
- Inc. Magazine profile
- Audio: What Business Can Learn From Open Source
- Video: "Be Good": Paul Graham at Startup School 08
- Paul Graham provides stunning answer to spam e-mails
- Techcrunch interview
- Roberts, Russ (3 August 2009). "Graham on Start-ups, Innovation, and Creativity" . EconTalk . Library of Economics and Liberty . <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>
- Arc website
- The Arc forum for users of the Arc language .
- A terse arc/lisp introductory tutorial
- practical-scheme.net/wiliki/arcxref an arc wiki
- The Hundred-Year Language , an essay
- Paul Graham's essays in all languages
- Pages with citations using unsupported parameters
- Webarchive template wayback links
- Use dmy dates from September 2012
- Wikipedia articles needing clarification from January 2017
- Articles with invalid date parameter in template
- Official website missing URL
- 1964 births
- Living people
- Lisp people
- English computer programmers
- Cornell University alumni
- Businesspeople in information technology
- Harvard University alumni
- O'Reilly writers
- Programming language designers
- American technology company founders
- Yahoo! employees
- British company founders
- Y Combinator people
- Pages with script errors
Navigation menu
Personal tools.
- Request account
- View source
- View history
- Recent changes
- Random page
- Infogalactic News
- Buy an account
- What links here
- Related changes
- Special pages
- Printable version
- Permanent link
- Page information
- Cite this page
- This page was last modified on 20 March 2018, at 21:13.
- Content is available under Creative Commons Attribution-ShareAlike License unless otherwise noted.
- This article's content derived from Wikipedia, the Free Encyclopedia ( See original source ).
- Privacy policy
- About Infogalactic: the planetary knowledge core
- Disclaimers
- Mobile view
IMAGES
VIDEO
COMMENTS
A Project of One's Own Fierce Nerds Crazy New Ideas An NFT That Saves Lives The Real Reason to End the Death Penalty How People Get Rich Now Write Simply Donate Unrestricted What I Worked On Earnestness Billionaires Build The Airbnbs How to Think for Yourself Early Work Modeling a Wealth Tax The Four Quadrants of Conformism Orthodox Privilege
Paul Graham ( / ɡræm /; born 1964) [3] is an English-born American computer scientist, essayist, entrepreneur, venture capitalist, and author. He is best known for his work on the programming language Lisp, his former startup Viaweb (later renamed Yahoo!
As a young founder your strengths are: stamina, poverty, rootlessness, colleagues, and ignorance. The importance of stamina shouldn't be surprising. If you've heard anything about startups you've probably heard about the long hours. As far as I can tell these are universal. I can't think of any successful startups whose founders worked 9 to 5.
Paul Graham is a programmer, writer, and thinker, mostly known as the co-founder of Y Combinator, the world's most successful startup incubator. In 2004 he released an anthology called " Hackers and Painters" which explores a variety of topics, from social and cultural issues to technical aspects of programming languages.
On Paul Graham's Essays, and of Y Combinator In literature, the ambition of the novice is to acquire the literary language; the struggle of the adept is to get rid of it ~ George Bernard Shaw Some of the finest prose I've ever come across has been in the pages written by Paul Graham.
Hackers and Painters: Essays on the Art of ProgrammingMay 2004 Author: Paul Graham Publisher: O'Reilly & Associates, Inc. 103A Morris St. Sebastopol, CA United States ISBN: 978--596-00662-4 Published: 01 May 2004 Available at Amazon Save to Binder Export Citation Bibliometrics Citation count 2 Downloads (6 weeks) 0 Downloads (12 months) 0
Here is the list of top-10 essays based on their reference-authority (PageRank) in all other essays by Paul. Beating the Averages. Lisp for Web-Based Applications. What You Can't Say. Revenge of ...
You could copy-paste it all into a word doc and export it to PDF. jason923 • 6 yr. ago. Short of previously published PDFs, you can 1) save each essay to Pocket for nicely formatted offline reading or 2) clip each essay to Evernote, also for easy offline reading.
In these essays, Paul Graham discusses the power of programming languages such as Lisp and how this non-conventional language proved to be a competitive advantage in creating Viaweb: Our secret weapon, Lisp, was similar. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses.
Ideas for Startups by Paul Graham Page 1 of 8 Paul Graham is an essayist, programmer, and programming language designer. The article below is one that he wrote about getting ideas for startups.
The answer is, the first component of importance: the number of people who care about what you write. If you narrow the topic sufficiently, you can probably find something you're an expert on. Write about that to start with. If you only have ten readers who care, that's fine. You're helping them, and you're writing.
Hackers & Painters: Big Ideas from the Computer Age is a collection of essays from Paul Graham discussing hacking, programming languages, start-up companies, and many other technological issues. [1] [2] [3] [4] [5] "Hackers & Painters" is also the title of one of those essays. Contents 1 Table of contents 2 Publication data 3 References
The essay is not the product of 13 ideas; it's the product of 1,000+ ideas, narrowed down to 13. Before that essay ever saw the light of day, Paul Graham sifted through many good, bad, and half-decent ideas, and selected the best. When Paul Graham starts thinking, he often finds dead ends.
About two years ago, the Lisp programmer and dot-com millionaire Paul Graham wrote an essay entitled Hackers and Painters, in which he argues that his approach to computer programming is better described by analogies to the visual arts than by the phrase "computer science".
all: clean venv fetch merge epub mobi : clean: : @echo " 🗑 Cleaning up the room...: rm -rf essays .venv graham.epub graham.md ; true: merge: : @echo " 🌪 Merging articles...: pandoc essays/ *.md -o graham.md -f markdown_strict count: : wc -w essays/ * | sort -n venv: : @echo " 🐍 Creating a safe place for a Python...: mkdir essays : python3 -m venv .venv
Paul Graham GPT. AI-powered search and chat for Paul Graham's essays. All code & data used is 100% open-source. Dataset. The dataset is a CSV file containing all text & embeddings used. Download it here.
Paul Graham ( / ɡræm /; born 13 November 1964) [1] is an English born computer scientist, entrepreneur, venture capitalist, author, and blogger. He is best known for his work on Lisp, his former startup Viaweb (later renamed "Yahoo! Store"), co-founding the influential startup accelerator and seed capital firm Y Combinator, his blog, and ...
An essay you publish ought to tell the reader something he didn't already know. But what you tell him doesn't matter, so long as it's interesting. I'm sometimes accused of meandering. In defend-a-position writing that would be a flaw. There you're not concerned with truth. You already know where you're going, and you want to go straight there ...