A few days ago I experienced the most embarrassing moment thus far in my career. I was trying to figure out why our Outlook addin wouldn't load correctly. I had spent parts of the previous two days looking into the issue but was only making slow progress. I narrowed it down to the fact that our bootstrapper wasn't executing and was thus trying to determine how some third-party code or weird COM issue might be causing this to occur. That's when I noticed the following in one of our classes:
//bootstrapper.Run();
That's right, the bootstrapper wasn't running because that line of code was commented out. Seriously.
I feel silly that it took me that long to identify the problem. It made my debugging ability and troubleshooting skills look amateurish. I think one of those monkeys that can move robotic arms with their minds could have identified the problem sooner.But that's not the worse part. I actually saw that line of code the day before and didn't think anything of it. At that time I checked the log for our code repository and noticed that the lead developer for the addin was the one who made the change, and the comment for that commit indicated that it was for some fix. Thus I didn't think twice about the commented out code. So not only did I struggle to find an obvious bug, but I could have found it much sooner if I had thought critically and not have blindly accepted things. Just downright stupidity and laziness on my part - and that's what's so embarrassing.
At the very least I need to take this as a learning experience and remind myself of some important things:
- Actively question things; don’t just take them for granted. The person who committed that commented-out line of code is a much better programmer than me, but that doesn't mean he isn't capable of making mistakes. I should have saw that line of code and discussed it with him instead of automatically assuming it was correct.
- The simplest explanation is usually the most likely and the best. The addin was working not too long ago, and then stopped working. Instead of digging into third-party stuff, I should have taken a step back and looked at the recent changes to the addin, as the simplest explanation is that one of our team's changes caused the problem.
- Don't commit prototypes and other exploratory code into the production codebase. That commented-out line of code was actually part of a prototype, and if it would have been committed to a separate branch instead of the production code branch, this issue never would have occurred (and I wouldn't have looked so stupid). Prototypes typically aren’t written with the same rigor and level of quality as production code, so the two shouldn’t be mixed.
- Commented-out code is terribly misleading and a waste of space. If the code is not needed, then just delete it. This point doesn't really apply to the abovementioned situation (and in fact, having that line there probably cut down on the time it took to identify the issue). Nonetheless, commented-out code is confusing and should thus be avoided.
0 comments:
Post a Comment