Design a rough over view / flow of your whole system in document / pictorial flow chart what ever.
Identify classes / their basic members / their interactions with each other.
Then try to walk through it and see if you have any issues. It is true that there are many problems which only appear when you actually get to code them.
But there would be many that become visible while doing this on paper and you have the opportunity to modify your design / data structure etc. right away without having to change a lot of code.
Getting better at this takes experience. But it only comes when you try to follow this strategy.
In the professional industry, you often have to submit design documents which go so far as to naming the functions and what they would be doing in a whole system prior to starting coding. This does not look very interesting initially but it is truly what distinguishes a software developed in a hap hazard manner and a professionally finished one.
Edit: One more and most important thing, always attack the hardest part of the program first, because initially you will have the most liberty to modify the rest of the system according to needs of the hard part. If you just keep it pending and do all the rest, you will be very limited when you get to solving the hard part with respect to data structures / interface available from other modules. Sometimes, you can't even find a work around and are forced to do the whole thing from more or less scratch.
Edited by fayyazlodhi, 24 June 2011 - 11:16 AM.
Forgotten point addition