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?

This is a perfect example of the excluded middle fallacy.  Yes, writing out the whole program on paper before you touch the actual keyboard is a bad idea.  But that doesn't make the opposite extreme--immediately jumping into the coding and starting to hack away--a good idea.  In fact, it's even worse.

It's very important to understand what you're trying to write before you start writing it.  When I've got a new feature to implement at work, I make sure I've got a spec that describes what needs done before I start.  I look it over, and if there's something on there that doesn't make sense, I talk with the people who wrote the spec and work over the issue until we're in agreement.  Sometimes I hadn't understood the requirements and they can set me straight; other times the PM folks didn't understand the technical details, and they end up modifying the spec.

Just about anyone who's done this can tell you from personal experience that it's a whole lot easier to fix problems in the spec than it is to find a problem in your code halfway through the implementation, rip it all out, and replace it with something else.  So having a plan for what you write before you start writing the code is very, very important.
