Ideas on Successful Software Design, Creativity, and Startups: Hackers & Painters

Hackers_And_Painters

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.

Paul Graham is an entrepreneur, programer, and venture capitalist. He co-founded Viaweb, which was purchased by Yahoo! and became Yahoo! Store. Later he co-founded Y Combinator, a seed capital firm. In 2004, Paul authored the book Hackers & Painters: Big Ideas from the Computer Age which comprises a series of essays on various topics including “Why Nerds are Unpopular,” “The Other Road Ahead: Web-based software offers the biggest opportunity since the arrival of the microcomputer,” “How to make wealth,” and “Design and Research” among many others. Each of these essays are available at Paul’s website. The book provides many great ideas on design, creativity, and startups.

The Test of Time: Predicting Successful Design in Advance is Hard
In chapter 2, Paul discusses similarities between hacking and painting. As others have noted, successful innovation is often at the edge of the current technology. Paul discusses beauty in the context of design and the difficulty in measuring success:

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

And there no correlation, except possibly a negative one, between people ability to recognize good design and their confidence that they can. The only external test is time. Over time, beautiful things tend to thrive, and ugly things tend to get discarded.

Paul notes cross disciplinary exposure is important to creativity:

I’ve found the best sources of ideas are not the other fields that have the word “computer” in their names, but the other fields inhabited by makers. Painting has been a much richer source of ideas than the theory of computation.

Try to Provoke a Design war in New Markets involving Tough Problems
Paul provides advice for winning against big companies when you’re a startup:

Only a small percentage of hackers can actually design software, and its hard for the people running [a big] company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design. If you want to make money at some point, remember this, because this is one of the reasons startups win. …. So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you.

But Paul says you it’s hard to get an established company into a design war. So, the best place to do so is in new markets. And “If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.”

Find Stars By Looking At Free Time Activities
How to do you find those hackers that can actually design software? Look at what they do in their free time.

When we interviewed programmers, the main thing we cared about was the kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects on your own.

In chapter 15, Paul talks about software design in the context of designing software programming languages. However many of the principles discussed apply to the design of any software and to design in general.

The Designer Should be an Intended User
Paul asserts that you must start by focusing on the user. But that does not mean doing exactly what the user says. Paul states, “I don’t think there is any field in which the best work is done by the people who just make exactly what the customers tell them to.” Yet, he provides that the designer should be one of the intended users:

You’re most likely to get good design if the intended users include the designer himself. When you design something for a group that doesn’t include you, it tends to be for people you consider less sophisticated than you, not more sophisticated. And looking down on the user, however benevolently, always seems to corrupt the designer. … If you think you’re designing something for idiots, odds are you’re not designing something good, even for idiots.

Paul analogizes to creation in other fields, noting that the design in software is for human use just as it is in other fields:

All arts have to pander to the interest and limitations of humans. In painting for example, all other things being equal a painting with people in it will be more interesting than one without. It is not merely an accident of history that the great painting of the Renaissance are all full of people.”

Paul notes that morale is important in design, “If you’re board when you’re drawing something, the drawing will look boring.” In art as in software design starting with a prototype that can be refined into the final product is helpful for morale. If you build software that can be working and testable in an hour, the prospect of that immediate reward is motivating. Similarly painters often “start with a blurry sketch and gradually refine it.” From morale Paul circles back to the problem with designing for the unsophisticated user, providing:

It’s hard to stay interested in something you don’t like yourself. To make something good, you have to be thinking, “wow, this is really great,” not “what a piece of shit; those fools will love it.”

Hackers & Painters is a great read with much more than can be touched on here. If you are a hacker, a startup, a maker/designer, or if you run a software company, you should read Hackers & Painters or you can read the essays on the web.