USE THE SURRENDER TACTIC ::: Frustration when debugging

Debugging is both a fun and frustrating process, it is fun when you keep finding and fixing the bugs in the shortest possible time while it is frustrating when you can’t find the root cause of or the bug it’s self.

Every programmer has a style that works best for them when it comes to debugging. Personally when a bug shows up on my radar I switch to ‘Hunt mode’: I analyze the error, think of a possible cause, check error logs, analyze the offending code and then set my traps until I catch the culprit. The traps can be anything from print statements, breakpoints , test scripts, to commenting out some code sections.

When the bug shows up, I do nothing else other than debugging. There is this time I spent three days on a bug, quit debugging on the fourth day out of frustration, resumed the next week and then fixed it after two days. In total it took me about 5 working days to fix the bug and about two weeks of zero work.
The problem here is not that it took me 5 days to fix the bug; but the fact that I put in two weeks of zero work due to my obsessive need to fix the bug. There is a restlessness you get before fixing a bug that diminishes the importance of everything else other than the bug itself, at that point the bug is the most important thing in your life, regardless of what your girlfriend says.

This never say die attitude has its advantages, in fact I credit it for having pushed me on early in my programming career but it is becoming a problem more so now that I have a boss I report to.

The Solution?

I am a follower of Robert Greens’ 48 laws of power and I am trying out one of his laws to solve my pickle and hoping it will work. Law 22: USE THE SURRENDER TACTIC: TRANSFORM WEAKNESS INTO POWER
“When you are weaker, never fight for honor’s sake; choose surrender instead. Surrender gives you time to recover, time to torment and irritate your conqueror, time to wait for his power to wane. Do not give him the satisfaction of fighting and defeating you – surrender first. By turning the other cheek you infuriate and unsettle him. Make surrender a tool of power.”

The law suggests that when faced with a question of what to choose; dying with honor like a martyr or surrendering to the enemy, the surrender option should be chosen. Greens’ laws inspire me in most of my other undertakings and when faced with this challenge I hope one of his laws will come to my rescue.

Way Forward::Hypothetical

After about two hours of debugging: surrender to the problem

Lay down your tools

Look no more at code

Restart the computer

Take a break, play a game or better retire for the day

While in surrender ponder over the following

Possible causes of the bug

Program architecture relative to the bug

Ask around if someone has a solution or if anyone else has ever hit the same wall

Share your story with a colleague, programmer or not.

Plan for the exit strategy (time to hit back at the enemy)

Ask yourself questions like how else could I have approached it

If you used a revision control tool (git, mercurial, svn, …) analyze the changes you made since the stable version

Write down a checklist of all the actions you need to perform next in chronological order.

Make a surprise attack on the enemy.

The above list is not a debugging best practice but a possible solution when faced with prolonged debugging sessions. Since I am going to use myself as the case study, I’ll report my findings after about six months.

Please feel free to add to the list what works for you, it might also work for the rest of us.