Paul Graham has a fine new essay entitled Hacking and Painting. It's very dense with ideas, and does a good job of describing the flavor of creative programming, something difficult to get across to a mass audience.
Hacking is like painting in some ways, but the analogy breaks down in others. Here's my take on some of the points.
If you want to hack, or paint, get a day job. In hacking, as in painting, it is very difficult to find a situation that rewards artistic accomplishment directly. Business and academia reward something that's different enough to be frustrating. I think that many people had the hope that the explosion of "open source business" would solve this problem, but it hasn't. The "day job" works for painters, musicians, and other artists, and is a good model for hackers as well.
Studying works of art is vital to learn to do art. The great painters learned by studying and copying other great painters, and refining the ideas. One of the best criteria for being a good writer is reading voraciously. Yet, as far as I know, it's rare to teach computer programming by studying great programs. Historically, a big part of the problem was the dearth of great programs available for study. Free software fixes this problem. I considered myself a hotshot programmer before getting involved in free software, but grew enormously through reading other people's code. I'm not sure how much code people study in academia; the Lions book is certainly one early encouraging example.
But: paintings last a long time, code rots fast. In museums and reproductions, we enjoy a body of work going back hundreds of years. In many ways, these old paintings are better than the work of today. Yet, with few exceptions, code that's hasn't been maintained for more than a year or so is dead. One such exception is code that performs a well-defined ask, and does it well (such as libjpeg). Another such exception is "retrocomputing".
Getting the spec right is more important, and more interesting, than implementing the spec. Once you've got a good spec, any competent programmer can implement it. (this is a good working definition of competence :) But coming up with a good spec is very hard. Usually the best way to do it is to incrementally refine an implementation. It's the same for painting - X-ray analysis frequently reveals things painted over and reworked. Oil paints are good for this kind of reworking. Analogously, dynamic languages are better than static languages for this kind of process.
There's a lot of discussion in blog land about static vs dynamic languages, and I expect to return to the topic. I consider programming in C to be like sculpting in marble, and programming in Python to be like sculpting in clay. They're both worth doing, but for different kinds of work. Also, giving a chisel and block of marble to a newbie sculptor produces similar results to a newbie C programmer: a pile of marble chunks covered in marble dust. Paul uses the similar analogy of drawing in ink vs pencil.
Programmers envy mathematicians too much; they should aspire to be more like artists. I see Paul's point here, but in the long run I disagree. Paul uses the analogy of paint chemistry as a scientific theory underlying painting, in much the same way that computer science theory underlies programming. But I think the analogy breaks down. Paint chemistry is obviously useful in predicting the appearance of colors, the way they'll interact with each other, the brush and the canvas, and other important stuff such as glossiness. But the limitations of paint chemistry are equally clear - as a theory it speaks not at all to composition, emotion, or the infinitely subtle issues of aesthetics.
But where are the corresponding limits in the theory of computer programming? This is an open question; certainly many attempts to apply mathematics to real programming have been disappointing. But I think this is because mathematicians aren't good at doing the kind of mathematics needed for programming, the kind where the spec (or the "theorem to be proved") is extremely complex. Indeed, the theorems most highly valued in mathematics are those where the statement of the theorem is very simple, but the proof is deep (Fermat's Last Theorem is a shining example).
Fortunately, there are people exploring that edge, "proof hackers" if you will. Metamath, HOL, and proof-carrying code represent some of the most interesting work in that direction. If these people succeed in expanding the useful scope of mathematical technique, then it will dramatically change the way we do programming
In this distant future, the use of mathematics will depend greatly on the type of programming being done. Aesthetics will still be important (without question in any area that deals with human interaction), but for well defined tasks and well defined properties (especially security properties), the best programs will be provably correct.
tree ISA vehicle
I see yet another suggestion that Max has the hacker mind. The other day, he discovered an undocumented feature in "Reckless Drivin'" - if you press the Alt key while clicking on Start, it pops up a dialog box that lets you choose a vehicle number.
So we started going through the numbers, and he enjoyed being able to drive cars, buses, go-karts, helicopters, and so on. Then, we found a vehicle code that corresponded to a tree. In a 2D driving game, it makes sense to consider a tree as a type of vehicle; it's rendered the same way, and even though it doesn't share all methods, it's probably easier to just leave methods for motion unimplemented than to branch out the class hierarchy.
Anyway, when Max saw the tree, he thought it was very funny, and laughed out loud. Was this because he saw a glimmer of the design of the program, and found the incongruity between the internal "tree ISA vehicle" and the real world, or is he just a happy kid who likes to laugh? Either way makes me feel good.