Don't let the bedbugs bite

If you've been a developer for a number of years you'll have come to terms with it by now : you will write bugs... often.
When writing a piece of software you tend to work towards one solution and get in a state of tunnel vision not seeing clearly the effects this new code can have on other features.
This in itself doesn't mean you are a bad developer. It is how you deal with those bugs that defines the quality of your work.
In past years I used a number of systems with various degrees of success. In this article I will describe my own experiences with these different approaches. These experiences may (and very likely will) be different from yours so feel free to comment and discuss in the comments below.
Also note that a bug tracking system can only be as good as the way you implement it in your workflow, something that most likely tainted my experience with at least one of the systems below.

Basecamp

The company where I started made use of Basecamp.
For those who don't know, Basecamp is a project management tool which allows you to share information, milestones, assets and much more with clients and colleagues on a project to project basis.
Or how they put it on their own website :

Basecamp keeps all your projects, data, and people in one place. No matter how many projects you have, or how many people you have working on them, Basecamp keeps everything organized.

As you can see it's a behemoth and one of the industries standards. For our purposes however it failed to please. We were a small company needing only a fraction of what Basecamp offered and for many projects clients insisted on using their basecamp, scattering around our to-do's in multiple places.

Taskii

Because the development team was getting frustrated with bug tracking in basecamp an intern got asked to create a lightweight todo program. This idea had been tossed around the development team for quiet some time but never found it's way to someone's desk.
The aim was making a standalone tool that could be installed on a developers machine in which they could manage their own todo lists. If you had the right permissions you could also add or modify todo's for colleagues.
The arguments for making our own tool were

• no costs (except for the development cost, which was underestimated)
• adaptability
• keeping our todo's on our own server
• in the long run even commercializing the product.

Even though @WWWillems made the most of Taskii with what we gave him the project was never fully operational. We had vastly underestimated all the small features a good bug tracker has to offer without really being noticed. After an initial testing phase and the conclusion of @WWWillems internship the project was abandoned.

Code Base

In the years that followed we mainly returned to basecamp untill codebase was coined as an option.
Starting from essentially the same promise as basecamp it's weird that codebase took our hearts by storm. Keep in mind that at this point we weren't only looking for a bug tracker, we also needed a place to safely store our code (svn) and track our time.
Codebase seemed to cater to all our needs and became a centerpiece of our development workflow.
It has to be said that at this point everybody on the team was convinced for the need of a bug tracking tool, something that hadn't always been the case. As stated earlier : a bug tracking system can only be as good as the way you implement it. That can't be overemphasized.
One way to get the most out of codebase is connecting your tickets to your source control system, milestones and time management system.
But in regards to bug tracking codebase has one major flaw: it can be difficult or even impossible to filter tickets in just the way you want it and getting to your tickets isn't a one click operation.
I still use codebase to manage projects I'm making in my free time. It's not overly expensive and gives me a place to not only track bugs but also store assets, ideas, code and documents and makes it easy to access them from any computer connected to the internet.

Mantis

I changed jobs at this point and in my current job there is no need for many of the feautures codebase offers.
Code is stored using Perforce on an internal development server while documents and assets are kept internally as well.
So when it came to choosing a bug tracker, codebase was deemed too heavy for our purposes.
Instead we went with Mantis, a bug tracker my colleague had used in the past.
Mantis is a bug tracker, nothing more, nothing less, but a very good one.
It is a little daunting to start out with as an empty Mantis database results in a home page only showing a vast amount of filters and no data. But once a labeling system is agreed upon and bugs/feature requests are starting to fill the system you can easily see how Mantis speeds up development time.
In addition to the default filters, you can create your own labels to add to issues (for example 'Reporter age' if you wanted to sort on bugs reported by kids of a certain age)
Once a filter is created you can store it as a permalink, a custom URL that allows you to bookmark the filter and access it in one click anytime you need that particular set of issues.
If you're looking for a good bug tracker and you don't need any other features I can highly recommend Mantis.

Pen and paper

To finish things up I have to add pen and paper as a last bug tracking device. Most developers I know have a habit of scribbling down to-do lists on different pieces of paper and often using them throughout a project.
This practice is sometimes necessary because you don't want to lose your train of thought by going to a bug tracking tool and filling in a detailed issue report while working on something else.
However, keeping to-do lists exclusively on paper is a dangerous practice that can lead to forgetting about certain bugs or even forgetting what 'label not correct' referred to in the first place.
So it's important to add these notes to your bug tracking solution of choice whenever you get the chance if you don't want to smack yourself in the head afterwards.