Test-driven development (TDD) is very popular at the moment. The basic idea is to code a series of test all of which fail, and then address the failures.
My approach is also incremental, but works in the opposite way. I like to get something working, and then add something else and get that working, and keep adding layers until the code does what is required.
It’s basically a cycle of write, test, fix, write, test, etc.
But the idea is that you are adding layers of functionality, and building on success.
Some of the additions are so simple that they SHOULD work fine, but I just do them and verify that they do.
The opposite approach would be to write a large amount of code and then test and debug it. But if we did that, the bug could be ANYWHERE!
When I started programming we were writing batch programs, and we had limited time on terminals. So we would write the code at our desks, and then get access to a terminal to enter it. Then we would run it (or get an Operator to run it for us) and we would take the output (report) back to our desks to debug.
That approach make no sense these days now that we have IDEs, debuggers, etc.
I should point out that I don’t think anyone else refers to this as “layering”, but for me the word conveys the idea of building layers of functionality which are demonstrably working.
Example
The COVID program holds 14 statistics for 3 counties plus the same for the world. It displays these statistics on six screens which the user can scroll though. But as I built it up, at one stage it was able to hold and display three statistics for one country. And before that it was able to display the raw results from a HTTP request. And before that, it was just able to display that it had managed to make a Wi-Fi connection to the router.
Conclusion
It is either arrogant or foolhardy to think that you can write substantial amounts of bug-free code. The best approach is to write small incremental pieces of functionality, proving that it is working correctly each step along the way