I disagree. I figure if I can't come up with a meaningful and reasonable name, then my understanding of the problem is incomplete. That is, if I've never named something before, that's because I've never had to think about it explicitly before. I'd rather sit and make sure my understanding is correct than plowing on through.
When my understanding of the problem is incomplete, I like to go through and just write functions and data structures first. It builds the high-level structure of the program before I get bogged down by details, and its easier to change the way it's structured when you only have function definitions than when you have half the functions written and realize you should have organized your data structures differently. When I write like this function names are pretty obvious because each function is named after exactly what it's supposed to do.
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.
I think you're right that it's basically outlining.
As a practice, it started for me when I first started working on writing some literate code. I would basically write a paragraph about what the function should do, then write up the function definition, then move on to the next program.
It has definitely made my code more coherent and feels like a necessity for anything more than a few hundred lines.
Lots of stuff I write I still just dive in and code because it's "obviously" simple. Sometimes that simple problem grows into a mess of 1k+ LoC, sometimes not.
I would agree, and add to this comment. If I can't figure out what the sensible name is then what exactly is it that I am writing? I have found that writing the wrong name even for a local private variable will often get me at least a little confused about what I am doing because it doesn't read correctly.
I'm someone else who renames things after writing the code to start with. It's not that my understanding is incomplete - it's more like I'm using different parts of my brain for holding the general shape of the code and coming up with words to explain it.
If I'm trying to get the shape of the code down before I lose it, then I'm thinking about what it does and how it does it. When I'm naming variables etc I'm thinking about explaining what it does in a way that's clear to me now, me later, and whoever else has to understand / maintain my code.
