Category: Startups

When I’m reading Kindle books I always highlight interesting sentences and paragraphs. I thought it would be good to have them in handy on a blog. The book “Hackers & Painters” is a collection of Paul Graham’s essays and a must-read for a developer aka hacker or non-technical startuper.

• Hacking and painting are the same. This came as a surprise to me. I always thought that developers and designers are the opposites side of one startup coin. PG even went to school to learn about painting which inspires me to improve my design skills.
• “You need a good sense of design to judge a good design” — this is obvious, but good sense of design could be (and must be?) developed. While good design is subjective to peoples’ opinion, time can show the difference between good and bad design both in software and graphics.
• “Big companies win by sucking less than other big companies.” In other words big companies try to minimize losses and risks by sticking to proven “good old” designs and products. As long as their competitors do the same, why bother? This is the main reason why startups could be more successful than big companies. Startup should do things differently, while big company can do what the other big companies are doing.
• Don’t give away information. The good source to learn about technology other startups use is their job openings. “The more of an IT flavor the job description had, the less dangerous the company was.”
• New design bring better ROI in new markets. Especially if the same people design and implement the product, e.g. Apple.
• “Most hacker don’t learn to hack by taking college courses in programming.” My own experience and observation prove the same. I often explain this to non-technical people who is contemplating to enter a career of a software / web developer or a programmer. There is only so much you can learn in a college or a university. The ratio of time and money spent to the practical knowledge gained is so low that I usually try to talk them out of it. Seriously :)
• Software specifications changes fast and far from perfect. This is an another advantage startups can use over big companies where feedback loop is longer and iteration cycles are longer too.
• “In hacking. like painting, work comes in cycles.” This one is very true for me. I can hack literally for 24 hours (especially during hackathons) and then don’t do any coding for a few days. Just read or catch up on my emails. Maybe it’s because our brains are more efficient when they focus on one type of tasks — “plug in”.
• Divide and conquer: each module or set of feature should have “an owner” who is responsible for making it shine. It communicates with other modules via interfaces.
• Programs should be written for people to read, and only incidentally for machines to execute.
• Practicing thinking differently big in life will make it easier to think differently on “small trips outside the box that people call innovative”.
• “Argue with idiots, and you become an idiot.”
• “Working to implement one idea gives you more ideas.” And the opposite is true by ditching the idea or delaying it other follow up ideas might never come or be delayed. “Get Shit Done” in other words. :)
• There are only two sufficient things to know about business: build something useful and make more than you spend. I would also add that best business is when you solve other people’s problems.
• “If starting a startup were easy, everyone would do it.”
• Doing a normal job usually means that you effort is averaged by the rest of the employees performance. Same for working in small groups and / or startups: working with better performing people rises your average! A-type person in a company where majority is Bs and Cs will be in a worse situation. In small, 5–10 people groups, it’s easier to measure effectiveness of individual contributor.
• Leverage is an impact you make and see in the end results. The best situation when you have both measurement and leverage.
• “Big companies can develop technology. They just can’t do it quickly. Their size makes them slow and prevents them from rewarding employees for the extraordinary effort required.”
• Chose the most difficult tasks, features, problems when making both strategical and tactical decisions — “run upstairs,” to get competitive advantage. “Start by picking a hard problem, and then at every decision point, take the harder choice.”
• Selling later for more is easier than earlier for less. Big “companies doing acquisitions are not looking for bargains.”
• The way to generate wealth is to please the customers by solving their problems. “Design your product to please the users.” And not to please VCs or potential acquirers.
• “Brand is the residue left as the substantive differences between rich and poor evaporate.” One of the reasons is that it’s “inconvenient to do something expensive and custom”.
• “Mistakes are natural. Instead of treating them as disasters, make them easy to acknowledge and easy to fix.” Everybody could fail. The characteristic of a strong person is raising up from the failures quickly and learning from them.
• Silicon Valley today is fifteenth century Florence, Italy. The power of same-minded people is real, powerful and unique.
• Cultivate and acquire domain expertise.
• Programming languages are not created equal. It’s easier to understand this by comparing low-level language like Assembly to high-level languages like C++ or Java. But the same comparison becomes harder for high-level languages, for examples PHP vs Ruby on Rails. In same cases it boils down to personal preferences, and considering how conservative humans in general, even to religious-like points of views / “wars”: “the language I’m using is the best!” BTW, if you are still using PHP, please take a look, if you haven’t already, at this article PHP: a fractal of bad design and take a glance at actual PHP hammer with two claws. You can only see the difference after you are exposes to more powerful / better things. It’s called “blub paradox”.
• “Object-oriented programming offers a sustainable way to write spaghetti code.” – http://www.codinghorror.com/blog/2007/03/your-code-oop-or-poo.html
• Technical “book should be thin, well-written, and full of good examples”.
• Be optimistic about solving the problem but skeptical about the quality of the solution at the moment.
• Get the prototype in front of users ASAP!

Graham, Paul (2008–07–14). Hackers & Painters: Big Ideas from the Computer Age (Kindle Location 2021). OReilly Media – A. Kindle Edition.