When to walk away from a difficult bug?

You have spent all day working on your new project. You’re on fire; many of the features you wanted to add are made. Confidence is building; there is no better feeling than taking your ideas and bringing them to life for people to enjoy (and purchase). You’re about to call it a day but decided to test the features you worked so hard to make.

Everything looks to be in order; nothing breaks as you’re testing functionality. On the very last test the void opens up. Darkness comes and snatches your very soul away from your body to drag you through the depths hell. After you return from your out of body experience you realize it wasn’t a hallucination due to your lack of sleep. The project you worked on does not function the way you need it to and has a program crashing bug.

Feverishly you try to find the cause of the bug. Changes are being made that are not being tracked because you are desperate to spend as little time as possible to fix this error. Code is breaking, more bugs appear that were either there before or were caused by you reckless changes. A single tear forms in your left eye as you wonder why you ever chose this profession in the first place.

We have all been in this situation before and it the worst issues always seem to happen right before a deadline. Maybe it is before the final project you need to submit for one of your computer science classes. Maybe your boss is breathing down your neck because you project needs to be demoed for a potential client. Whatever the case may be we can all agree that code breaking bugs suck. Luckily the ways to deal with difficult bugs is fairly easy.

Walk away. If you have been coding all day then it is likely that you are fatigued and need to walk away. You need to destress your mind. Go have a snack, take a brisk walk or simply go catch some ZZZs. Leave the desk and go do anything not related to programming for at least a few hours, it would be best if left your code alone until the next day. It is easier to troubleshoot issues when you have fresh eyes, when you have been working all day you end up getting tunnel vision. What could be a simple logic error can be missed when you are looking for a bigger problem that does not exist.

Peer reviews are also a great way to solve problems. Your classmates and/or co-workers are a great resource to look over you code. They can easily spot things you may have over looked. I know some developers might not want to go down this route because of their pride or they don’t want to look stupid in front of others. As long as you’re not constantly asking for help for small issues and are putting in time to figure it out yourself then you are fine to ask for help. Don’t let ego get in the way of making progress.

You might find your own little hacks to deal with bug issues and that’s great. Practice whatever techniques that work for you and be open to share those strategies with your peers. Stay productive and don’t let minor issues affect you and your projects.