Failing to design is designing for failure
(With apologies to Alan Lakein)If you are new to programming the temptation is to just get in there and "cut code". It feels productive to have an impressive slab of code to show as quickly as possible. In fact, rushing in and cutting code straight off is the least productive thing you can do. Going straight to code is like starting to build a house by sawing up some timber and banging in some nails, without any plan or blueprint.
Before cutting a single line of code you need to have a very clear, preferably written, understanding of what the program is to do. Then you need a design. The design is essentially a plan that breaks the task at hand down into subtasks or functional blocks that are each responsible for some part of the overall program objective. Techniques you can use here are flow charts, state diagrams, decision tables or whatever else works for you. The vital point is to understand and map out the functionality independently of any code.
A well thought out design becomes not only a plan for generating the code. It is also a guide for testing and debugging. Later, if changes are required, the design becomes a map that allows you to find your way around the code and mentally test, in the abstract, the effects of proposed changes.