Doing something for the first time is always the hardest.
Hence no amount of planning can trully prepare the developer for a solution to the problem.

Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better.
Rather than having talks with people of what could be and what not.

Correct. This is why almost all internships do diagrams and charts rather then pure coding. Conceptual understanding is critical, or you're just coding blindly. It's also an easy way to spot a very obvious bug that could be over looked in development. What saddens me is when people bash charts and diagrams, claiming it to be useless. For some, such things may be a hindrance. But here's my outlook on it: 1 great programmer can not program nearly as good as a 100 moderately good programmers working as a team. While it's critical to be confident, its crucial to identify when confidence is tainted by belligerence and ignorance. I would much rather work with the person that needs the flow chart and communicates well with me than someone who is too good for anyone else. So yes, communicating to the point of what is needed (typically in a chart or diagram) can be of a invaluable asset for leadership and direction, which means more man power to complete the larger task at hand.

Doing something for the first time is always the hardest.
Hence no amount of planning can trully prepare the developer for a solution to the problem.

Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better.
Rather than having talks with people of what could be and what not.

Correct. This is why almost all internships do diagrams and charts rather then pure coding.

This is contrary to my experience. Certainly I was working on the codebase from the start in all of my own internships. Most other people I've talked to also worked on the code during their internships and only used diagrams as prototyping or documentation aids. Maybe this depends on the company, but every place I've worked has preferred that I use my skills to actually write code and accomplish things rather than play with diagrams all day.

1 great programmer can not program nearly as good as a 100 moderately good programmers working as a team.

I don't think those are really comparable and I'm not sure I see what you're getting at beyond the obvious (more people = more man-hours). Sometimes you neither have nor need 100 moderately good programmers to do something and happen to have a great programmer on hand; would you advocate dropping the great programmer and hiring 100 moderately good programmers? Plus, those 100 moderately good programmers could have trouble communicating with each other, leading to much lost productivity. There is such a thing as too many cooks in the kitchen and adding more people beyond a certain point does not automatically mean more actual work being done.

I would much rather work with the person that needs the flow chart and communicates well with me than someone who is too good for anyone else.

The bold text is what I think is the real issue. You want to work with someone who thinks like you. But do you really need the flow chart or diagram if the person can explain an architecture or algorithm to you without it? Is a programmer who can explain how the code works without a diagram really "too good for anyone else?" After all, ultimately a flow chart or diagram is just a tool we use to communicate with each other. There are other ways of communicating ideas.

There is something called the Technical Design Specification. It is a book, created by the designers and in part, the developers of the SDLC. It encompasses just about every diagram you can think of:

I cannot seem to find the book with that title.

I'll tell you what my experience over the years has been. When I was very green, I didn't do much planning at all. I just sat down and started writing code. If the problem was geometrical in nature (as is often the case in 3D games), then I maybe had some diagrams that I drew, but those were really only for the geometry of the problem, and nothing to do with the final code design. My code designs were awful, by the way. I remember one class that took 12,000 lines of code because it did everything. Obviously, this concept of coding by the seat of my pants wasn't working.

So, I switched philosophies. I decided that I was going to plan everything beforehand, with class diagrams and whatnot. My new motto was, "A receptionist who doesn't know C++ ought to be able to implement this from my documentation alone." I felt that I shouldn't write a line of code unless I can prove that it works on paper. Yeah, that didn't work out too well for me, either. It's like trying to see 100 moves ahead in chess.

Here's the thing. A new programmer doesn't have the ability to take a complex problem, break it down in their head, and then immediately sit down and start coding -- nor do they have the ability to sit down and plan the whole thing out with UML-like diagrams. I can't speak for everybody, but I had to go through this rigmarole of trying solutions, realizing they were crappy, and doing it differently next time. For me, there was no way to short-cut that process.

These days, I can do a much better job reasoning about complex problems in my head, and having a good intuition about what form the solution should take. I'm also better at planning complex problems on paper. So, I used to suck at both. As I gained experience, I got better at both. Go figure.

I always write a little something beforehand. Doesn't have to be much. At the very least, it helps to write down a set of goals and requirements so that I don't go off-track. And, of course, I'm working on a team, so it's often the case that I need to communicate my ideas to others, and that usually entails writing some documentation. Other than that, I tend use notes and diagrams as a sort of secondary storage -- it's difficult for me to keep zillions of details in my head, so if I think of something that I don't want to lose, I write it down. That about sums up the balance I've found for myself.

Before a single code is worked on, the Technical Design Specification should be completed.

Honestly: Does it really work that way in your company?

In my 17 years as software developer this never happened.

Problem 1: You cannot write a meaningful spec without prototyping and testing, and this includes: Coding.

Problem 2: If you write a full spec, the relevant people will not read or understand it. And in the end, when you show your final product, these people will state that they wanted something completely different.