How do you get from a set of requirements to a working program? There is no cut-and-dried recipe to follow.
If there were, someone would write a program to do it, and computer programmers would be obsolete.
However, there are general principles you can follow that will help to guide you toward a solution. (Based on How to Solve it by George Pólya.)
In the real world, this is sometimes the most challenging part. Without this, the product you create (i.e the code you write, the design you create, etc.) will be completely off from what an instructor or client is expecting.
However, this is probably the number one thing people know they need to do when getting some kind of assignment or job. How can you ever be expected to code hundreds, possibly thousands of lines without fully understanding what you are doing?
If you don’t have a way to test an assignment or job and make sure it fits the necessary requirements set by your instructor/boss then you will move forward ignorant to the potential issues.
This obviously can cost you letter grades or more importantly money & time!
One of the most commonly used methods for this is stepwise refinement (AKA the top-down design). This is a process of breaking up the original problem into some number of smaller sub-problems.
Next, you take each sub-problem and break it up into even smaller sub-problems. This is repeated until you get sub-problems that are small enough to be translated into code.
This approach can be extremely helpful to not only beginners trying out something new or difficult. It also can help people who have been doing this for years. The process of getting the idea, transitioning it to paper, and then working through the problem, allows you to understand the issue quicker and easier.
OK, this is probably the most anticipated part of the whole process. Seems simple right? It should be after your extremely thoughtful planning and design work. You can see that the process doesn’t work if you go from step one to step four.
Another side note here is the amount of time you plan and design. Like dieting and losing weight, the workout or the cardio is only a small part, the diet is the biggest percentage. This is the same as coding. The planning and design is the majority of the work while the actual coding is only a small part.
Last but certainly not least, the reflection. I usually write notes of issues I had while writing the actual code or if I found something better that I didn’t know about. If you keep a notebook nearby to jot down notes you can go back to them when you are implementing something.
The reflection also allows you time to go back through, add testing measurements if need be and ask things like, what worked and what didn’t? How can this experience help you solve future problems? Which of course leads to you being a better developer in the long run.