Paul Graham said something very similar about figuring out a program:
"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."
As a CS student currently at university, my experience has been identical. I also can't help but notice a similarity between these ideas and the methods of agile software development, where at each iteration you produce a working approximation of the final software, taking into account new information and new specification changes as you go.
The people who taught you to architect programs before coding were also aware of this trade-off.
It's a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I've written a lot of big programs, and I've never regretted the time spent architecting them. I have som...
Followup to: Don't Fear Failure
In the same theme as the last article, I think that failure is actually pretty important in learning. Rationality needs data, and trying is a good source of it.
When you're trying to do something new, you probably won't be able to do it right the first time. Even if you obsess over it. Jeff Atwood is a programmer who says Quantity Always Trumps Quality
The people who tried more did better, even though they failed more too. Of course you shouldn't try to fail, but you shouldn't let the fear of it stop you from tyring.
I wouldn't go as far as to say that quantity always trumps quality, but where the cost of failure is low lots of failures that you pay attention to is a pretty good way of learning. You should hold off on proposing solutions, but you also need to get around to actually trying the proposed solution.
I'm normed such that I'll spend more time talking about if something will work than trying it out to see if it works. The problem is that if you don't know about something already, your thoughts about what will work aren't going to be particularly accurate. Trying something will very conclusively demonstrate if something works or not.
Note:
I originally had this as part of Don't Fear Failure, but that post got too long.