If you think about it, this is basically outlining. You know, that thing your English teacher always bugged you to do because it would make your essays more coh

If you think about it, this is basically outlining. You know, that thing your English teacher always bugged you to do because it would make your essays more coherent. If one insists on writing code before understanding the problem, this is probably one of the better ways to do it. Recognizing that function names are obviously correct because you know exactly what their purpose is in relation to the whole is a good sign. When I first started programming I wrote a lot of code without much planning, and it was good because it allowed me to learn a language faster by interacting with it. When what should have been pretty straightforward programs started to get unwieldy, I realized that I had to do something different. Now I go at it with pencil and paper before writing any code, and I find it much more productive and fun because the level of understanding is better. It's so easy to write code and it seems like it's so easy to change, but with any non-trivial problem I think that this is really an illusion. There are many times when it is useful to write exploratory code without much planning, but I think it's mostly useful for learning a new environment or banging out a minor variation of something you've done before. Otherwise it seems more useful to do some fairly systematic planning, even if it's for a prototype that may get completely reworked over a number of iterations where requirements are explored and may change.