Intro
In a book first published in 1969, Swiss-American psychiatrist Dr Elisabeth Kübler-Ross introduced the 5 stages of grief model, representing an in-depth analysis of the components of this process. The model was later refined further to include a total of 7 stages. The seven stages include shock, denial, anger, bargaining, depression, testing, and acceptance. The bargaining and depression stages have less relevance for the purposes of this article so they have therefore been omitted.
Not unlike these stages, many of us have gone through a similar journey when we come across a bug in the software and products we have been creating, even more so when it happens to be brought to our attention by our users.
Using this model as structure and metaphor for the rest of the article, allow me to share some thoughts and experiences I have had over the last few years working closely with Software Engineer colleagues when things haven't always gone exactly to plan, handling these unexpected hiccups, and going from chaos to clarity.
There is little to no evidence that people move sequentially through the stages in order, but I am sure many of you would have been in a situation where at least some of what follows would be relatable.
Shock
We've all been there at some point, the disbelief and sub-second initial paralysis at hearing the news... we've got a bug! This news alone shouldn't be enough to cause any real harm, but I'm sure those who have broken production or accidentally caused data deletion can attest, levels of severity when it comes to bugs can be the difference between a minor increase in heart rate, or the creation of a few extra grey hairs.
It's important to clear the mind and get back to a logical mental state so that you can act fast to address the issue at hand.
Denial
In many cases, the first instinct might be to look for evidence that the reported bug is a red herring and couldn't possibly be true as "surely we have checks and balances, and tests in place to prevent such occurrences?". We wish to find such evidence to prove our assumptions to be true, if this was the case then "no harm no foul" would be the quote of the day.
At some point or another, we all have fallen into the trap, to some degree, of believing the diagnosis is somehow incorrect while we cling to a preferable, albeit false, reality.
Keeping a cool head when presented with evidence to suggest that all is not right with your corner of the world is key to allowing the switch from defensive to investigatory states. While it is always good practice to verify the report for validity, accuracy, and scope of impact, these two different approaches will have vastly different outcomes on the resolution, especially in keeping with a user-first mindset.
Anger
Depending on your particular personality type, if you feel anger it's likely to be aimed at yourself or the situation. When dealing with a critical bug the situation can be stressful when the weight of the responsibility to resolve the issue as soon as possible comes into play. This can allow for the unintended outpouring of bottled-up emotion, that probably has little to no relevance to the actual bug itself.
Build an environment where in the event of a bug or an issue the course of action is not to assign blame, but rather to identify the situation and steps that lead to the cause of the incident, then address it accordingly so that the same is unlikely to reoccur in the future.
Testing
Finally... on to something more positive, and where the real debugging resolution begins!
In this stage, you will be more aware that you are unable to change the situation that would have initially caused or continues to cause the bug or issue affecting the product and users. You likely find yourself actively seeking out and looking for realistic solutions to address the problem. This exploration is fundamental to being able to resolve the issue and lays the groundwork in preparation for what's still to come.
"Working the problem" is a great skill set to refine as you gain more experience as often it's less to do with what you already know which will give you the edge in successfully debugging an issue and much more to do with how you can approach an unknown and still get things done when the path isn't straightforward or clear.
Acceptance
To complete the metaphor this stage could ultimately be summarised into the phrase finally finding the way forward or I know how to fix this.
Confidence begins to rise as you start to see the solution to debugging the problem, implementing a solution, and deploying a fix all start to take shape — the light is visible at the end of the tunnel as a result of your efforts, and salvation is near for the affected users.
Conclusion
This by no means is an extensive list of the trials and tribulations we may come across on any given day (and how we can overcome them) as Software Engineers or Product Managers working in the SaaS industry.
The takeaway here should not be the anxiety-inducing flashbacks that some of what was laid out above may cause when thinking about production mishaps and the like, but rather the growth opportunities presented throughout that can be built upon to approach the next debugging situation wiser and more strategically — with a particular focus on the Testing and Acceptance phases.
The only time it would be necessary to view the need to engage in debugging activities as unfavourable is when learning doesn't occur as the result at the end of the process.
