Paul Graham's excellent "Hackers (HackEr) and Painters" piece 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...

So why do universities and research labs continue to judge hackers by publications? For the same reason that "scholastic aptitude" gets measured by simple-minded standardized tests, or the Productiv Ity of programmers gets measured in lines of code. These tests are easy to apply, and there is nothing so tempting as an easy test that kind of works... I think hackers just have to resign themselves to having a large random component in their reputations. In this they are no different from other makers. In fact, they're lucky by comparison. The influence of fashion is not nearly so great in hacking as it is in painting...

I've found that 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...

I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape... If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong... Realizing this has real implications for software design. It means that a programming language should, above all, be malleable (Agile Programming Language). 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...

Unfortunately, most companies won't let hackers do what they want either. Universities and research labs force hackers to be scientists, and companies force them to be engineers... They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it's hard for the people running a 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 (Making A Living) at some point, remember this, because this is one of the reasons startups (SmallCo) win. Big companies (BigCo) want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low... 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. These opportunities are not easy to find, though... 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...

• So one way to build great software is to start your own startup (SmallCo). There are two problems with this, though. One is that in a startup you have to do so much besides write software... The other problem with startups is that there is not much overlap between the kind of software that makes money and the kind that's interesting to write... All makers face this problem... I think the answer to this problem, in the case of software, is a concept known to nearly all makers: the DayJob... (The greatest damage that photography has done to painting may be the fact that it killed the best day job. Most of the great painters in history supported themselves by painting portraits.)... This is what Open Source hacking is all about...

One thing we can learn, or at least confirm, from the example of painting is how to learn to hack. You learn to paint mostly by doing it. Ditto for hacking... The other way makers learn is from examples... Hackers, likewise, can learn to program by looking at good programs - not just at what they do, but the source code too. One of the less publicized benefits of the Open Source movement is that it has made it easier to learn to program...

Another example we can take from painting is the way that paintings are created by gradual refinement... The structure of large companies makes this hard for them to do, so here is another place where startups have an advantage... Great software, likewise, requires a fanatical devotion to beauty... But if the hacker is a creator, we have to take inspiration into account...

The example of painting can teach us not only how to manage our own work, but how to work together...

Like painting, most software is intended for a human audience. And so hackers, like painters, must have empathy to do really great work... "Programs should be written for people to read, and only incidentally for machines to execute."... (The way to make programs easy to read is not to stuff them with comments. I would take Abelson and Sussman's quote a step further. Programming languages should be designed to express algorithms, and only incidentally to tell computers how to execute them. A good programming language ought to be better for explaining software than English.)...

So, if hacking works like painting and writing, is it as cool? After all, you only get one life. You might as well spend it working on something great. Unfortunately, the question is hard to answer. There is always a big time lag in prestige. It's like light from a distant star. Painting has prestige now because of great work people did five hundred years ago... What we can say with some confidence is that these are the glory days of hacking... 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. In some ways, the time lag of coolness is an advantage. When you meet someone now who is writing a compiler or hacking a Unix kernel, at least you know they're not just doing it to pick up chicks.

User Options Recent Changes Help Page