My reading notes of Hackers and Painters’s Chinese version can be found in a blog post which was written in 2011.
This is an important book for my career, which inspired me to take the path to step out from the Acedamic and became a software engineer. I cannot really understand the value of startups and the spirit of hackers until recent years when I experienced different cultures of start-up and cooperation. Thanks for this book and my choice made in my mid 20s, I had a fruitful early career in a wonderful start-up company and I will always be grateful for my younger self who worked really hard to find the way out and for a group of great people lifting me up.
Some inspirational quotes from the book:
About research
Everyone in the sciences secretly believes that mathematicians are smarter than they are. I think mathematicians also believe this. At any rate, scientists tend to make their work look as mathematical as possible. A page of formulas just looks so impressive. (Tip: for extra impressiveness, use Greek variables.) And so there is a great temptation to work on problems you can treat formally, rather than problems that are, say, important.
Unfortunately, beautiful things don’t always make the best subjects for papers. Number one, research must be original– and as anyone who has written a PhD dissertation knows, the way to be sure that you’re exploring virgin territory is to to stake out a piece of ground that no one wants. Number two, research must be substantial– and awkward systems yield meatier papers, because you can write about the obstacles you have to overcome in order to get things done.
The way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way. This kind of work is hard to convey in a research paper.
About software engineering
Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it’s there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.
What and how should not be kept too separate. You’re asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it’s creating the spec.
About start-up
When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.
The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That’s where you can win big by taking the bold approach to design, and having the same people both design and implement the product. Microsoft themselves did this at the start. So did Apple.
