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.