A debugging story

Today, I was helping a coworker fix a bug.

At first glance, it didn't seem as if it would be too hard to fix.

The problem was easily reproducible. Sometimes reproducing a bug depends on rare race conditions or odd work environments. The bug we had appeared every time you did a certain sequence of steps. So, we were off to a good start.

I was able to find (and run) a version of the code where the bug didn't exist. So I knew, that somewhere along the way, some discrete code change created this bug. Maybe, all I'd have to do do was go through the list of changes until I found the nefarious one.

This is where things got difficult. Even though I had an old bug-free version and a new buggy version, there were too many changes between then and now. Running a diff between the two version was useless. I tried to undo half of the changes, to try to narrow down where the bug first crept in.
That didn't work so well, as the project failed to build due to all sorts of incompatibilities.

It was like searching for that proverbial needle in a haystack. I felt like I was on a wild goose chase. Everywhere I turned, it was another dead-end.

In the end, I never found the bug. My co-worker ended up figuring it out, before I could.

Even though I didn't find the bug or check in any code, I think it was still a worthwhile experience. I got to think deeply and learn about a piece of code that is related to things I work on. It's always good to have more code-context and knowledge.

I also spent a good deal of time thinking and being confused over some javascript language details. In particular, I thought the cause of our bug was that the code depended on a 'for loop' iterating over a javascript object in a particular order. As it turns out, this was a safe assumption, and not the cause of our bug.

My takeaway from this is the following: if you want an ordered list (when all else is equal), use an array instead of a javascript object. Both may work, but an array has a more intuitive order. Most people wouldn't question the order of an array, and wouldn't waste time trying to verify that iterating over an array in a specific order works or not. Just because the computer (and other language experts) will interpret something correctly does not mean it is the best way to code. Writing code that the average programmer can understand is almost always better.

All in all, this debugging session is typical of many debugging sessions. It's never as easy or as hard as you expect. The bug is often not where you expect it to be. You often feel like you wasted a lot of time.

But if all goes well, you have improved your code base and learned something along the way.