This question already has an answer here:
- Over thinking development 9 answers
I was thinking today about Paul Graham's book "Hackers and Painters." More specifically, these two paragraphs:
"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 was a kind of final pass where you caught typos and oversights... [It] seemed like programming consisted of debugging.
... 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."
That's how it's taught in my college and I'm pretty sure most other colleges as well. You figure out what your program will do, and then you figure out how to do it, then you type and debug. Sometimes you make a basic version and add functionality, but the idea is that you think through and then type.
This sort of reminds of that chapter in Feynman's book called "He Solves Radios By Thinking!" where he paced around thinking of how the radio could be broken, and then fixes it. To me, that's what programming is about - thinking and then finding a solution.
Is this the prevalent approach to coding? If so, why don't more people just hack away and put a program together without having a preconceived idea of what it's going to look like?
What are the advantages and disadvantages of think & type vs. spew & beat?