There is much argument and discussion in the industry about how to do this. Basically there's four things you need to do:
- Get the requirements. Specify what the program needs to do. That is, be very clear on what the goal is.
- Plan how the program is going to work. What are going to be the primary classes/object? What is the data going to look like? How is the process flow going to work? This can get as detailed as writing an outline of what each method will do, such that the outline will become the comments for the code. It is especially important to plan how different parts of the system will interact.
- Implement the plan. Write the actual code.
- Verify the code. Does it work? Does it meet the requirements?
The trick is that sometimes things don't go smoothly. You start planning, and you realize that there's a problem with the requirements: something is missing, or something is contradictory. You start programming and you realize the plan is based on faulty assumptions. You have to go back and redo the plan, and hope that doesn't reveal any problems with the requirements. It's good to have some idea how you are going to manage having to go back and make changes, which might affect work already done.
You might not even do it in the above order. Some people like to verify the code before it's written. That may sound odd, but what it means is that they write the tests the code has to pass first, then as they are writing the code they can make sure it passes each test along the way.