on bugs (the software kind)

This week at work, I’ve fixed quite a few bugs in the new application I’m working on.  I never know what to think when it comes to fixing bugs in an application. On the one hand, it’s good to make software work correctly, of course: it pays the bills, and there is a sense of satisfaction that comes from it as well.  On the other, there is always the possibility that I was responsible for the bug in the first place (as has been the case many times this week), so that’s never fun.

We have sometimes played a game at the office affectionately known as “who’s the blockhead” where we examine the history of code to see who’s responsible for the really insidious bugs. it’s all in good fun, really; no one’s job is at stake or anything. But even so, it’s always a little sad to see when it’s your fault.

I don’t tend to talk about my job much in this space: most people probably wouldn’t find it particularly interesting. But there is one thing that I think is pretty unique about software development: it’s one of a very few professions where workers are fully expected to have issues come up regarding their work that are a) unintended consequences of well-intentioned effort, and b) can occur some time (years, even) after the work has actually taken place.  I don’t think there’s a programmer out there that has written anything non-trivial that has never introduced a bug into their code.  In the end, you just hope that the ones that you’re responsible for aren’t too bad and that you can fix them quickly.