While Joel Spolsky thinks that every bug should be fixed before new code is written, the reality in many places is that developers are very busy, and some bugs are deemed worthy while others are not. Unit testing is also often treated as nice to have.
I have been chasing a mysterious bug in a critical application, and found a few minor ones in the process. I mentioned them to the original author, and he said something like "Oh yeah ... I remember QA raised these 3 years ago but they were shut down".
I suppose some developers are better at multi-tasking at others. With me personally - I like to work on one thing at a time, and even if there is a 0.1% chance that an unimportant bug might be interacting with a serious one, I have an urge to just fix an unimportant bug first (understand it better in the process too) and not think about it later.
On one hand I would be wasting my time on what business analysts deemed not worthy. On the other - I might be able to fix the important bug faster if I can focus on just that one task.
Before I try to make this argument, I wanted to ask what your thoughts and experiences are with a situation like this. Question is marked as community wiki. Thanks.
Just remember that whenever you change code you might introduce new bugs, so by fixing those small bugs deemed to unimportant to fix, you might accidently introduce a new serious bug. Sometimes that's a risk worth taking, but on some, critical, systems you should never touch any code without good justification. So what kind of system you're working on can be an important factor for answering this question.