Technical: The "break out the notebook" is close. Use the scientific method in your debugging. By this I mean form hypotheses about the bug and test them ... ri

Technical: The "break out the notebook" is close. Use the scientific method in your debugging. By this I mean form hypotheses about the bug and test them ... rinse and repeat. The important bit here is that you keep track of the hypotheses you come up with and the way you tested them. This track serves as proof of your work that you can ask for a co-worker to examine for its effectiveness. You don't need to do all the hypotheses testing yourself if your hypothesize about some part of the system that a colleague is more familiar with. No shame in asking for help here, even if it is repeatedly denied. Managerial: Ask how to improve. Are bugs being prioritized properly? If some level of management is not involved in prioritizing bugs, ask them to take and look and prioritize. It is not enough for you to think "hmm .. no hurry to fix this bug for the next release 'cos its a very obscure case and there are these other important ones to tackle first." Self management: If you're overwhelmed by many bugs and are zombied about where to begin or touch next, just pick whatever looks the easiest to fix and fix it, irrespective of priority (and loop that). This at least gets some momentum going. A management that expects bugs to be fixed exactly in the prioritized order is ignorant. That's not how systems fail. What might be thought of as trivial might turn out to be very significant, and vice versa.