"Hackers & Painters" Excerpts [1]

1. Paul Graham has a complete philosophy of entrepreneurship. His formula for entrepreneurship is:

2. Build a prototype

3. Launch (don't worry about bugs)

4. Collect feedback

5. Adjust the product

6. Grow big He encourages startups to release products quickly because this allows them to know as early as possible whether an idea is viable.

7. In 1984, Newsweek reporter Steven Levy published the first book in history to introduce hackers—Hackers: Heroes of the Computer Revolution. In this book, he further summarized hacker values into six "Hacker Ethics," which are still considered the best statement in this regard today:

8. Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-On Imperative!

9. All information should be free.

10. Mistrust authority—promote decentralization.

11. Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.

12. You can create art and beauty on a computer.

13. Computers can change your life for the better.

14. When what you do can produce real effects, it's not just fun anymore; finding the right answer becomes important.

15. I've found that the best sources of new ideas for hackers are not theoretical fields with "computer" in their names, but other creative fields. Instead of looking for ideas in "computation theory," you'd be better off looking for ideas in painting.

16. I now think that the programming methods taught to me in college were all wrong. The time to figure out the whole program should be while you are writing the code, not before you write it. This is exactly what writers, painters, and architects do. Understanding this has major implications for software design. It means that the primary characteristic of a programming language should be malleability. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen.

17. Another problem with startups is that profitable software is often not fun software; the overlap between the two is not high.

18. All creators face this problem (referring to the other problem with startups: profitable software is often not fun software, and the overlap is not high). Price is determined by supply and demand. The demand for fun software is not as high as the demand for software that solves customer problems. The pay for performing in a small theater is not as high as the pay for wearing a cartoon gorilla suit and standing for a vendor at a trade show. The return on writing novels is not as high as the return on writing ad copy. The income from developing programming languages is not as high as the income from connecting some company's old database to a server.

19. How can hackers do what they like to do? I think the solution to this problem is one that almost all creators know: find a "day job" to support your family. This term comes from musicians who perform music at night, so they can find another job during the day. More generally, "day job" means: you have a job for money, and a job for love.

20. For hackers, it is very beneficial to adopt an approach like painters: you should regularly start from scratch, rather than working on a project for years and trying to include all the latest ideas in the form of revisions.

21. Excellent software also requires a fanatical pursuit of beauty. If you look inside excellent software, you will find that the parts that no one is expected to see are also beautiful. I take code far more seriously than I take other things.

22. Hackers are like painters; they have psychological cycles when working. Sometimes, you have an exciting new project, and you're willing to work on it 16 hours a day. After that burst, you feel bored and lose interest in everything.

23. The process of eliminating bugs is like solving a math problem. Given many constraints, you just need to solve the equation based on the conditions.

24. The correct way to collaborate in code is to divide the project into strictly defined modules. Each module is clearly responsible by one person. The interfaces between modules are carefully designed. If possible, it is best to write the documentation as clearly as a programming language specification.

25. The best way to use software should fit the user's intuition. Don't expect users to read the manual.

26. Programs are written for people to read, and only incidentally for machines to execute.

27. A good programming language should explain software better than English. Only in places that are immature and prone to problems should you add comments to remind the reader to pay attention, just like warning signs only appear at sharp turns on the highway.

28. Observe how trends are generated and try to predict what words it will ban. which group is powerful but highly nervous? What kind of ideas does this group like to suppress? Have there been any social struggles recently? Which side lost, and what kind of ideas were implicated by them? If a vanguard wants to stand out, what kind of ideas will he support? What kind of ideas do conformists fear?