So a Product Manager Asks You to Fix a Bug…

As a full-stack developer, it‘s a situation I‘ve faced more times than I can count. I‘m deep in the zone, working on a complex feature or refactoring some legacy code. Suddenly, a message from a product manager pops up on Slack: "Critical issue in prod! Customers are seeing errors on checkout. Can you investigate ASAP?"

My heart sinks a little. It‘s not that I don‘t enjoy problem-solving or making things better for our users. Quite the opposite – it‘s what drew me to software development in the first place. But I also know that interruptions and context switching carry a heavy cost. It takes "more than 23 minutes to recover from interruptions" and get back into a productive flow.

But when duty calls, we answer. I dive in, asking the PM for more details. When did this start happening? What are the exact error messages? How many users are impacted? Is it failing consistently or intermittently?

According to a study by the Cambridge Judge Business School, the average software developer spends "21% of their work time dealing with technical debt and bad code". Bugs are inevitably a big part of this. The more info I can gather upfront, the more efficiently I can debug.

Luckily, we have a mature bug tracking system in place. The PM quickly files a Jira ticket with user reports, screenshots, and steps to reproduce. I‘m able to locate the relevant logs and exception stack traces.

It looks like a null pointer is being thrown in our checkout service when the order amount is zero. Tracing the git blame, I see this code was recently modified to add support for coupon discounts. The engineer must have missed an edge case in their tests.

I consider my options. I could add a quick null guard and push a fix, but that feels like slapping on a band-aid. The proper solution is to refactor the service to gracefully handle zero-amount orders end-to-end. But that will take more time and testing to get right.

Every bug fix comes with this tradeoff. Do you go for the quick patch to mitigate user impact, or invest in a robust long-term solution? Too many quick fixes and you end up with a codebase full of tech debt and brittle workarounds. But if you always strive for perfection, you risk prolonged downtime for your users.

In "The Mythical Man Month", Fred Brooks argues that "the bearing of a child takes nine months, no matter how many women are assigned". Some problems can‘t be solved with brute force. Sometimes the best thing we can do is step back, think carefully, and do it right, even if it takes longer.

But this bug seems like a true edge case, unlikely to have any wider ripple effects. I implement the quick fix, write a regression test to cover it, and open a ticket for the deeper refactor as a follow-up.

With the immediate fire put out, I circle back with the PM. I explain the root cause of the bug and why I chose the quick fix. I reassure them that a longer-term solution is queued up and walk them through the relative priorities. Clear communication is key to keeping everyone on the same page.

Empirical research shows that high-performing DevOps teams consistently prioritize both speed and stability. The DORA State of DevOps report found that elite teams deploy code 208 times more frequently and have a 7 times lower change failure rate compared to low performers. They achieve this by investing heavily in automated testing, CI/CD, and transparent processes around quality and reliability.

Bug fixes are no exception. By capturing every bug report in a system like Jira or GitHub Issues, we create a transparent backlog visible to the whole team. Automated alerts from logging and monitoring systems can automatically create tickets and notify the right people. Clear labeling and prioritization lets us know what to tackle first.

Over my career, I‘ve found that proactive communication is the best way to keep bug fixes smooth and productive. When a PM or customer reports an issue, my first response is to acknowledge it and set expectations on next steps. Something like: "Thanks for flagging this! I‘m looking into it now. I‘ll post an update within the next 2 hours with either a fix or an ETA on the solution."

This accomplishes two things: it reassures the reporter that their issue is being taken seriously and worked on. And it creates an explicit time window for me to investigate and respond with a meaningful update. If I get pulled into deep debugging and don‘t surface a clear update or timeline, people naturally get anxious.

Daily or weekly bug triage meetings are also hugely beneficial. This is a chance for developers, PMs, and QA to review open bugs, adjust priorities, and brainstorm solutions together. It surfaces any blockers and keeps the backlog healthy. Importantly, it‘s also a chance to celebrate the bugs that were squashed and recognize the people doing that important work.

No bug is an island. Chances are, the issue you‘re seeing is a symptom of wider quality or process problems in your codebase and team. Be on the lookout for patterns. If the same type of bug keeps cropping up, you may need deeper refactoring, more robust testing, or improved alerting to detect issues sooner.

Fixing bugs quickly is important. But fixing them for good requires zooming out and examining your development practices holistically. Are you writing code with maintainability in mind? Investing in automated tests and quality checks? Leaving time to pay down tech debt? Taking a pragmatic approach to technical tradeoffs?

Bugs may be inevitable, but how we approach them is very much in our control. By instilling a culture of quality, communication, and continuous improvement, we can keep our users happy while still shipping at a rapid clip. Next time a PM asks you to fix a bug, take it as an opportunity not just to solve the immediate problem, but to make your system a little more resilient for the future. Your team and customers will thank you.