Andy Chase

If you 'make computers do stuff' for a living, Hackers and Painters is well worth a read. Probably the best stand-out quotes from Paul Graham's essay (thanks to Jason Clark for posting them on his own site; they're what lured me in):

"For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. 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. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. 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. You should figure out programs as you're writing them, just as writers and painters and architects do."

"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."

The doing has always been the attractive aspect of programming for me; getting a task or an idea, and going right for the text editor and banging out a code sketch that more or less works, and then going back to fix/polish it has always seemed like the natural way to do things.

It's not that I couldn't sit down and spend several months creating a giant UML diagram and functional specification, it's just that the process always gets mired in the minutiae of making sure Proper Software Development Procedures are being accurately followed, and attempting to anticipate every single possible task or user interaction that might conceivably be needed. When it comes time to implement the spec, it's terribly difficult to reach that trancelike, coding-into-the-wee-hours state because you're trying to force your abstract, idealized design into reality... and methodology dictates that Now Is Not The Time To Be Making Design Decisions, even if it's become apparent that implementing feature X is going to be torture because of some unforseen language/library shortcoming.

On the other hand, when you enter the realm of large, complex software projects the rosy picture of "Programmer as painter, working on the masterpiece as (s)he goes, free of constraints and able to make beautiful code" is not entirely realistic. I haven't done enough of this on a large scale to know where the balance between planning and execution is, but I do know that I absolutely feel more effective when I'm hacking away at something than when I'm trying to write it as pseudo-pseudocode in Microsoft Word... even with a language I know pretty well, it's just not possible to declare how X will work in a specification, and have complete confidence that the actual code implementation of X will be practical, or even possible. In most cases it is, but it's the cases where adhering to the spec is a problem that make the whole excercise so frustrating.

I still like Peter Norvig's Teach Yourself Programming in Ten Years essay, which points out that it takes a long time to figure this stuff out, even if you did go to school for it.