It's not always a bad thing, IMHO. But the key is that when you start writing code in order to solve a problem you don't fully understand you should be doing it in order to understand the problem better, and because it is the fastest way for you to do it. You should be willing to throw the code away once it has served that purpose. Concomitantly you shouldn't put any more work into that code than is necessary to serve that purpose.
I'm a big believer in prototyping certain difficult problems. I actually spent about 6 months last year just prototyping various aspects of a problem I am working on. I also did a lot of pencil and paper work during that time. The reason was that the problem really was very difficult (for me at least,) and also very hard to precisely define. So we would develop an idea for an approach, and then code a bit to see if it worked out. In a lot of cases that revealed that our idea was flawed, so we would go back, think up another approach, and then code up the simplest test of it we could.
One big danger is that you will start coding before you understand a problem and get so attached to your sub-optimal code that it winds up in the finished product. Another is that you will spend way too much time "gold-plating" something that is never going to work.
One way we avoided this was implementing our prototypes using a higher-level (and ultimately too slow) language and a much lighter-weight platform than we were eventually targeting. We ignored a lot of the rules of good software engineering- our code was not meant to live much past the point where it had answered our questions satisfactorily so over-engineering it would have been a waste of time. We did the absolute minimum we had to to get the answers we needed. And we worked as much as we could out on paper or a whiteboard before starting a prototype.
I'm a big believer in thinking things through as far as you reasonably can in advance. But sometimes you need to code something up to make sure what you are thinking makes sense. When to think and when to code (well, hopefully you keep thiniing while you code ;) ) is a hard question, and like a lot of things in software development, a matter of judgment.
EDIT: The main thing I wanted to get across here is that I think it's important to know why you're coding. Some code is meant to wind up in production. Some code is meant to answer questions. Where you get into trouble is confusing the two.