Turning Architects into Programmers II

Some more thoughts on turning Architects into Programmers.

I'm going to talk a little bit about "Hackers and Painters" by Paul Graham.

I can recommend reading the whole thing, if you haven't already. If you've not come across Paul Graham before, he's a LISP advocate, which means he does descend into bashing strongly-typed languages occasionally, but there is a lot of good stuff in there if you overlook the brief evangelism.

Here are some choice quotes if you really don't have the time to spare...

"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. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better."

And...

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

It's sobering reading for those of us who consider ourselves as hackers (or pirate dwarves, if you will), especially the parts about not forcing hackers to be engineers or researchers. I wonder if the other doctorate students on my course also consider themselves as hackers in the first instance and become research engineers as a concession to accepted job roles?