What most of the people have said: every programmer makes mistakes (even Carmack), good programmers make fewer mistakes and fix them sooner. If you've been avoiding bug fixing it makes your job harder. If an area of code has many bugs they may interact in weird and wonderful manners than make diagnosis difficult. But still possible. Get to a better mindset, then get to it. You'd regret abandoning your hard work.

To fix a bug ridden codebase:
- Set compiler warnings to the max, set compiler to treat every warning as error, and fix (or silence) the errors.
- Add a lot of asserts, specially for function preconditions.
- Make sure you read return values everywhere, and check them for errors.
- Rename poorly named classes and functions to be more clear.
- Use const-correctness.
- Fail fast

If using visual studio:
- Set debugger to break whenever exception is thrown.

Is you codebase riddled with null-checks? Optional codepaths if/when something fails?

http://www.martinfow...re/failFast.pdf

Some people recommend making your software robust by working around problems automatically. This results in the software "failing slowly." The program continues working right after an error but fails in strange ways later on. A system that fails fast does exactly the opposite: when a problem occurs, it fails immediately and visibly. Failing fast is a nonintuitive technique: "failing immediately and visibly" sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production.
[/quote]