Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When programmers are confronted with bugs in their applications, they typically progress through what psychologists call the five stages of grief. These stages are a series of emotional states people experience when dealing with tragedy or loss in their lives.
It may seem a bit odd that something as common and benign as a bug could trigger this type of emotional reaction, but, in a way, it makes sense. Our applications are like our babies. We create them. We raise them. We watch them grow, all in the hopes that, someday, they will be able to set out on their own (and make some money to support us in our old age).
It is natural that we are affected when someone tells us there is something wrong with our baby.
Oh no! My baby has an object reference error!
As a programmer, you must be able to overcome these emotions quickly and effectively. Otherwise, you can linger and stagnate in one or more of these stages. Developers who recognize how their feelings affect their performance stand a much better chance of finding a timely solution to their problems. With that in mind, let’s take a look at how the typical developer progresses through the five stages of grief when dealing with a bug:
Stage 1: Denial
Bugs? What bugs?
Bugs may be inevitable, but you sure wouldn’t suspect it from the way the average programmer typically responds to a bug report:
• “That can’t be from a bug in my code! I bet the .NET library is causing this to break…”
• “Are you sure you tested this right? You’re probably not using the application correctly.”
• “That’s impossible! My code is perfect!”
The mere suspicion that a bug may exist can put a developer in defense-mode. It is as if bugs were personal affronts to our honor that sullied our good name. It’s a funny reaction because deep down we all know that the bug probably does exist, but that won’t stop us from clinging onto the hope that perhaps this time our application is working as expected.
There are some among us who will happily bury their heads under the sand for as long as humanly possible. But, to our credit, most of us quickly overcome this stage. Luckily, most bugs that are reported are reproducible, which leaves a developer no other option but to address them.
Stage 2: Anger
Now this is a stage we could spend some series time in…
• “Why wasn’t this caught earlier in testing!?”
• “Why does so-and-so’s code break so often!?”
• “I’m already busy. Now I have to deal with this!?”
• “GRRAAAHHHHHH!!!”
Most programmers are very well acquainted with this stage. We all know how cathartic it can be to let out our inner code monkey rage. In the end, we need to recognize that all the screaming and yelling and breaking of keyboards doesn’t solve anything. All it does is kill time, burn bridges, and make us look like whiny jerks.
In the end, we’re still left staring at the same bug, only now we have even less time to fix it. Not to mention the substantial damage control we may have to run after that exclamation point-filled tirade we sent to the company e-mail list.
Yeah…this year’s company Christmas party is going to be mighty awkward…
Stage 3: Bargaining
Okay, so we’ve acknowledged that there is a bug in our application and we’re done griping about it. Now what?
Look for the path of least resistance, of course! That database corruption problem? No problem. We’ll “fix” it with some manual modifications to the database. That pesky null object reference error keeps popping up? Just wrap everything in a try/catch block!
Programming is easy!
At this stage in the debugging process, we are usually presented with two options. We can either:
• Fix the problem the right way, once and for all.
• Throw together a hack and hope it works
Option #1 is obviously the right choice, but option #2 sure is much easier. After all, a hack is quicker to write and will probably hold up well enough for the time being. And even if it doesn’t, what are the chances you’ll be the one who has to deal with it?
To some extent that is all true. It’s like putting off emptying the garbage can. You can get away with it for a while, but eventually someone’s going to end up in a pile of filth.
Stage 4: Depression
Programmers love to whine. It’s easy to feel sorry for ourselves. Our work is constantly scrutinized, analyzed, and criticized.
Due to this, we end up spending a considerable part of our working hours fixing bugs instead of what we want to do: create video games (admit it, it’s true).
Debugging isn’t what any of us signed up for. Most of us love to create, but abhor having to maintain our creations. It is here that a lot of developers hit a brick wall. They are paralyzed by the dread of the inevitable work that will ensue. If you find yourself in this situation, it is important that you recognize it.
You are far better off taking a break and going for a walk than you are just sitting at your desk feeling sorry for yourself. At the very least, you will come back rejuvenated and (hopefully) ready to tackle the problem.
Stage 5: Acceptance
Finally, an end to this emotional gauntlet! We’ve acknowledged the existence of the bug, vented our frustrations, resisted the temptation to throw together a hack, and finished feeling sorry for ourselves. Makes you exhausted just reading about it…
Most people fail to realize that debugging is an emotional roller coaster for programmers. The constant ups and downs that come with the five stages of grief cause a great deal of strain on our psyches.
This is undoubtedly one of the major sources of stress in our occupation and could explain why so many of us burn out so quickly and so suddenly. It takes a certain type of person to be able to endure this day in and day out. And while your managers, friends, and family may never acknowledge your suffering, you have my deepest sympathy.
To those who are about to debug, I salute you.
Kevin Pang is an ASP.NET developer and an ALT.NET supporter. He blogs about software development.
