I like to write simple functions and methods in a real-life context, compile early and often, use the debugger to halt and see what happens. This ensures that at least for my case, the method works. Sure, I might take a bit longer, but the result is code which works and only contains little bugs which only need small fixes. It sometimes takes months to find them, because they might be edge-cases or just not interesting for the application I am writing.
Also I use a very old principle called "self-healing code", which simply means that I expect that somethig will throw or fail, but I catch the error, try to analyse and correct it in the algorithm itself, or else propagate it to the topmost level, where I present the error in an understandable way. By doing that, I can find out easily what went wrong when a poblem occurs
do unit tests, too. Let the computer test all the cases which were not interesting while you wrote the code so you can make sure that future usage will also just work.
The last point is: I have a very distinct way of writing code. My code looks consistent, no matter which part of the application I take a look at. I take pride in being strict with my way of writing my code. And I read my code several times after I finished it (just like an important letter) and try to re-understand what I did there. That ensures that the logic I thought of is implemented in the right way and that I know my way around the code base, even when it is huge and I do not work on certain parts very often.