Paul Graham’s article Hackers and Painters is the best that I have read about software development in a long time. This sentence captures its topic:

Because hackers are makers rather than [computer] scientists, the right place to look for metaphors is not in the sciences, but among other kinds of makers [such as painters, writers, and architects].

For the moment, I’ll just quote the things I underlined as I read it while eating lunch:

Realizing [that you should figure out programs as you’re writing them] has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking about programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen.

Another one:

The fact that hackers learn to hack by doing it is another sign of how different hacking is from the sciences. Scientists don’t learn science by doing it, but by doing labs and problem sets. Scientists start out doing work that’s perfect, in the sense that they’re just trying to reproduce work someone else has already done for them. Eventually, they get to the point where they can do original work. Whereas hackers, from the start, are doing original work; it’s just very bad. So hackers start original, and get good, and scientists start good, and get original.

Another one:

Another example we can take from painting is the way that paintings are created by gradual refinement. Paintings usually begin with a sketch. Gradually the details get filled in. But it is not merely a process of filling in. Sometimes the original plans turn out to be mistaken. Countless paintings, when you look at them in xrays, turn out to have limbs that have been moved or facial features that have been readjusted.

Here’s a case where we can learn from painting. I think hacking should work this way to. It’s unrealistic to expect that the specifications for a program will be perfect. You’re better off if you admit this up front, and write programs in a way that allows specifications to change on the fly. […]

Everyone by now presumably knows about the danger of premature optimization. I think we should be just as worried about premature design – designing too early what a program should do.

Yet another one:

If a hacker were a mere implementor, turning a spec into code, then he could just work his way through it from one end to the other like someone digging a ditch. But if the hacker is a creator, we have to take inspiration into account.

In hacking, like painting, work comes in cycles. Sometimes you get excited about some new project and you want to work sixteen hours a day on it. Other times nothing seems interesting.

To do good work you have to take these cycles into account […]. In both painting and hacking there are some tasks that are terrifyingly ambitious, and others that are comfortingly routine. It’s a good idea to save some easy tasks for moments when you would otherwise stall.

In hacking, this can literally mean saving up bugs. I like debugging: it’s the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is to solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you’re going to win in the end. It’s as relaxing as painting a wall.

I really like this, but I’d like debugging more if I could use better tools, which I can’t at the moment. But I really like to relax by doing some refactoring for a while. Now for the last one:

Source code, [like the user interface], should explain itself. If I could get people to remember just one quote about programming, it would be the one at the beginning of Structure and Interpretation of Computer Programs. “Programs should be written for people to read, and only incidentally for machines to read.” You need to have empathy not just for your users, but for your readers. It’s in your interest, because you’ll be one of them.

The above was posted to my personal weblog on May 12, 2003. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)