Debugging Life Problems

It is a painful thing
To look at your own trouble and know
That you yourself and no one else has made it
-- Sophocles, Ajax

Debugging, despite being one of the most useful engineering skills to have for programmers, similar to other valuable skills, its a really hard science to master. But whats the matter with life?

We all know that life is like mountain climbing, filled with all sorts of ups and downs. There are moments or periods of time we are suffering badly that we want to know the reason desperately. The process of figuring out the why of those life problems or struggles is similar to how programs are being debugged. To debug effectively, we need to stabilize the error first, or in other word, make it reproducible. Many bug reports mandate reproduction examples. Anthony Fu had a great article explaining the why. Equally in life, if the same mental problem consistently drains our motivation, it might be a good time to dive a bit deeper than simply tolerate it.

However, we know that the root cause of a bug may not be on the surface, it could lurk deep in the stack trace. If we only look at what went off at the moment, which is what people usually do, we might only catch the surface. If we attempt to fix whats on the surface, say you have a workaround with some hard coded values, it may get your test suite to pass, but its a false positive. Instead, we need to understand what brings us to the situation. In program, we get the help from stack trace. Stack trace represents a call stack at a certain point in time. In life, a series of events or choices weve made in the past may give us more clue. To leverage stack trace for debugging, we need some kind of logging. This is usually being done by searching our memories. The problem with counting on our memories is that they arent as reliable as we would wish. This is where journaling comes into the scene. It may require a bit extra effort, but it gives a more undistorted view of what had happened before.

Although sometimes the root cause may directly be told from the error message, its not uncommon that we need to trace down the call stacks for more insights, especially those Caused by lines. The lowest caused by may often be the root cause, besides they hide deeply that you need a lot of patience to uncover them. Similarly, five whys is a good technique for root causing real world issues, including the struggles were dealing with. Patience is the key, dont panic.

After carefully analyzing the available evidences, we form our assumption. Making the right assumption is critical. For example, assuming its my fault is a good assumption while pointing fingers is not. When bugs popped up, theyre much more likely caused by application code we wrote rather than framework or language constructs, thus its wiser to chop down the stack trace to lines associated with our own code. Jeff Atwood even calls this first rule of programming. When things didnt work as expected, like when betrayal happens or relationship sinks, its always more rational to take the responsibility to reflect on ourselves rather than blaming others. This isnt easy either, our ego will keep us blind from our mistakes. Self-defense is part of human nature, but true growth often comes from taking the harder road.

Then we need to validate our assumptions. Its usually done by taking actions and reviewing results. Again, journaling helps. It could be a repeated process since we might fail a couple times and our assumptions turned out to be wrong. Persistence is the key, as long as there is progress, were slowly moving towards the goal. Finally the bug is fixed, time to party right? Yes, but hold on for a second. Conducting a post-mortem reflection that summarizes lessons learnt plus diligently asking ourselves where else in our life the same lesson can be applied, this will curate long-term thinking that our future selves will be grateful for and save us from making the same mistakes again.