Applying lessons from debugging code to life

 

Caterpillar and pupa

Last few weeks I was full-time engrossed in writing code and debugging it. This is a common activity for software developers. There are things fundamental to the process of debugging that apply to life as well. Let's call them foundational pillars of debugging. The purpose of this post to share the parallels I see between debugging code and debugging life.

Definition of debugging (source: Wikipedia)

“Debugging is the process of finding and resolving of defects that prevent correct operation of computer software or system.”

“A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.”

With formalities out of the way, here come the six pillars of debugging.

Acceptance

The first pillar is accepting that software is not working as expected. If one is in ignorance or denial of the existence of an issue, debugging can not begin.
In the software world, it is not a big issue, but in life lot of people are in denial. There is no acknowledgment of the existence of a bug. They either don’t see the problem or don’t want to see it. Denial => No debugging.

Authorship

The second pillar of debugging is knowledge of the fact that we control the code which has the bug. If we have no control over the code then why bother? Again this is very obvious in the software world, but not so in life. People don’t want to believe they wrote the code which is manifesting the bugs in their life. It is easy to blame circumstances, organizations, governments, God, nature, destiny etc.
Debugging doesn’t work this way. The code of life is our thoughts, beliefs, knowledge, habits, assumptions, actions, feelings, decisions and speech. The bug(s) exist in this code.

Awareness

Bugs in the code don’t announce themselves. One needs to look for them. This involves becoming aware of each line of code that exists and its behavior. Developers use tools like code review, log statements, debuggers to get this awareness.
The tools to get awareness in life are reflection, meditation, coaches, self-help books and programs, journals, counselors therapists etc. The key is to understand the internal wiring as it exists.

Causality

The fourth pillar is establishing a cause and effect relationship between some part of the code and the manifested external behavior. What in the code could be causing the issue we are seeing? This is not guesswork but real cause-effect analysis. It is an Aha! moment when one sees the root cause and how it manifests as the observed issue. Discovering blind spots is sheer joy. It is only one step away from setting things right.

Change

What needs to change in the code to stop the unintended effect? What change will start manifesting the intended effect? Making that change is the fifth pillar. Insanity is doing the same thing over and over again, expecting different results. Sanity is to arrive at a different result by doing something different and needed. Once you have identified what needs change - Do it.

Validation

The sixth and the last pillar is to test that the change solves the purpose and doesn’t break something else. Solving the problem completes the debugging process. Else go back to pillar 1 and repeat.

I hope this post inspires you to fix a few bugs in your life. It inspires me to fix some in mine.

Caterpillar and pupa

PS. Originally published on March 13, 2017 on LinkedIn.