NEVER ignore a bug, they don't just go away and it may come back to haunt you.
The ultimate aim of good programming is to reduce the bug count to an absolute minimum. Unfortunately the definition of a bug is not particularly simple. A bug may cause a program to crash, generate a few unwanted results, or compute completely the wrong thing. The worst form of bug is the conceptual bug, where the programmer misunderstood what was needed. The functional requirement may even develop over time during the research process. Effective algorithmic testing is the only way to ensure that conceptual bugs are found and eliminated. Good performance evaluations rarely lie.
For complicated software try to test with data for which you know the exact solution.
Write groups of 10-20 lines at a time. All new software should be interactively stepped through in a debugger, as it is written, to check that each line behaves as expected. Variables should be examined to check that they are within sensible bounds and loop variables should be tested to ensure they do not pass outside the valid data domain. Attempting to avoid this process will result in software which is ultimately more difficult to debug.
When finished any associated test data sets should be preserved so that further modifications can be tested. Such test data sets are generally best kept as software research demonstrations. This ensures that the software will get tested at regular intervals during the normal course of activities.
Software should NEVER be modified without assessing the effect on an associated test data set. This is the only way to reduce the average bug count, you can't rely on version control to do this for you. Modifying software without testing is probably the best definition there is of `hacking'.
Avoid completely rewriting software. This immediately increases the total bug count in established code. It is far better to identify a continuous development path and modify one feature of the program at a time and test each step. This is particularly important for mature software which may have been debugged over a period of years by a group of programmers and for which you may not understand all of the complexities (OLD CODE IS BETTER THAN NEW CODE).