• 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.

We do a couple of things at hashnode to minimize bugs,

• Test Everything - Most of the time, bugs occur when you merge a new feature with the existing code. In those situations, you will not know whether there is a bug until somebody in your team notices it or worse users notice it in the production environment.
• Write Documentation - Unless it is your personal project, the codebase will be used by multiple people on your team. Writing comments in the code helps reduce bugs when somebody else works on or uses a piece of code which you wrote.
• Linting - Linting not only normalizes how your code looks throughout the codebase, it also helps you avoid common error-prone code which you might write.

Test Driven Development or TDD is one approach that really helps in this aspect.

TTD basically means you write failing tests before actually implementing the feature. Then you code up the feature to make the tests pass. Then you repeat the process for the next feature.

TDD not only minimizes the possibility of bugs in your code, but it also makes you more confident on your code and its behavior.