Ask anyone writing software "what's the toughest bug you faced?" and they probably have something they won't quickly forget. The longer their career, the more interesting the anecdotes get. Timing issues, unable to reproduce mysteries or something which took days to figure out. If you would ask them the total amount of bugs they fixed it's something nobody bothers counting and rarely a meaningful statistic. Generally, you will have a handful of hall-of-fame-bugs and dozens of things you can't even remember fixing.

Most bugs are just that: forgettable. Annoying and affecting users but not rocket science. A major sign of dysfunctional software delivery is when people forget this. It's especially common when teams are under pressure to estimate everything upfront, creating a culture where "I don't know" feels like failure rather than the starting point of an investigation. Work isn't triaged and there's a constant fear of even analyzing issues because things are considered "too complex" and already nominated as a hall-of-fame-bug without even knowing what's going on.

Don't fix what's not important

Not all bugs are worth fixing. Some testers are great at testing. They find bugs which even users cannot reproduce. Doing basic triage (severity/frequency/cost/risk) should be the first priority. Cost (time/effort) and risk are hard to accurately assess without taking a closer look. An often occurring problem is that this analysis is considered overhead or just not fun to do. Maybe you work in a sprint and have 3 weeks to clear the work assigned. Looking at anything on the backlog is considered "scope creep" and "loss of focus".

Then the next sprint comes and there are 5 bugs on the backlog and nobody can accurately estimate them. Nobody knows the effort it would take to fix them. You can't just put them in the sprint! Not estimated! Spikes! Commitments! I'm not advocating for any kind of rule here - find out what works! - but there should be some sort of workflow to do the triaging. Especially the cost analysis.

Ideally, it should come naturally and everyone should feel responsible and triage work as it comes in. In practice, this hardly works because there's always more important work to do. Setting some time apart is advisable. Be it in refinements or other designated time slots.

Just dive in

The most underrated skill in software development is to just roll up your sleeves and actually fix problems. Or at least get to a point where it's possible to describe what the problem is. That doesn't mean moving fast and duct-taping stuff together: problems still need the right solutions.

What sets someone miles apart is how effectively they can analyze bugs. Sometimes you just need one person spending 15 minutes checking logs, zapping through a code base and reproducing the issue whilst others are still debating story points in endless meetings.

This investigative instinct is not a talent you are born with or without: it's a skill you can acquire and get better at. Instead of theorizing about potential edge cases and being fearful that you might not find an answer: just dive in. Most bugs are not hall-of-fame worthy. They just need one person properly looking at them. Even if you don't get to the exact solution, some time spent actively looking at it will perhaps result in enough context to describe and estimate more accurately.

Conclusion

Sometimes software delivery gets to a point where we rather spend time discussing than actually finding out what's wrong. More time is spent on discussing bugs than actually analyzing and triaging. You cannot estimate the unknown. Dive in, get a better picture and re-evaluate. Most bugs aren't hard to fix.