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.