Troubleshooting and debugging a website is one of my strengths, and as such, much of this came naturally to me. It wasn’t until I started training new web designers that I realized it wasn’t obvious to everyone.
Here I have tried to take the steps that I follow to make troubleshooting and debugging simple and put them down on paper (in a manner of speaking). If you practice each of these steps, I promise that troubleshooting will seem more like an enjoyable obstacle course to overcome than an insurmountable mountain.
Step 1. Slow down.
Don’t rush in writing your code, and especially don’t rush the troubleshooting process. As you near the end of a particular aspect of any project, it is easy to get antsy and try to ram through the rest of it. At this point coding gets sloppy and mistakes are easily made.
The problem is amplified when you feel like you should be done and it should be working. Finding a bug in a site that isn’t easily fixable when you thought you were done can start to raise feelings of anxiety. I have seen developers flail about in reckless attempts to squash a bug. I calmly tell them to stop so I can look at it, and after a minute they are embarrassed when I tell them they are missing a semi-colon or bracket, or they misspelled a word, or they have a conflicting line of code further down the page.
If you find yourself getting frantic, step away from the computer, get some water. Go outside for some fresh air, then come back and calmly address the problem. Slow down.
Step 2. Write clean, well-documented code to begin with.
Step one flows right out of step two. I know it seems obvious; everyone knows that you should write clean, organized code with plenty of comments. Yet, few of us take the time to do it. It is a lot like exercise. Sure, we all know it is good for us, but bringing ourselves to step out the door for a jog is easier said than done.
Clean code is an investment in your future. The time you put into well-organized, human readable code will pay off in the end. Not only in reducing the amount of bugs, but making it easier to troubleshoot when there are problems.
Step 3. Test often throughout the project.
Not only should you test at regular intervals throughout your project, but you need to test thoroughly. Anytime you are creating a website, you should have the four main browsers open, IE, Firefox, Chrome and Safari, and you should regularly refresh the page to catch a bug quickly.
Waiting until you are halfway through to check your site in each browser will waste hours of work. If you spend all your time developing in one browser and at the end decide it is time to test the website in the other browsers… well, maybe you should consider a career change to print design.
Step 4. Isolate the problem.
Once you encounter a problem, figuring out what caused it shouldn’t be too hard if you have been regularly testing. Finding the problem is a lot like finding your lost car keys; start by retracing your path backward. Undo each of your recent changes in reverse until the problem goes away. At which point you should know what caused the bug.
If that doesn’t work, because maybe it never worked to begin with, you need to reduce the code to its most basic elements. Strip it out of context and put it in a very controlled environment. The key is to remove as many variables as possible, then add them back one by one, once you have it working.
Step 5. Talk to others about it.
Talking with someone, even someone who has no idea what you are talking about, can have tremendous benefits. Just the exercise of voicing your problems can be enough to help you see it from another perspective and give you new insight.
Better yet, it is important to have a support network of other web designers or developers that you can bounce ideas off of. Fostering these relationships early on, before there is trouble, can have untold benefits on your personal development as well.
It isn’t unusual for someone on the outside to see immediately what the problem is. How often have you not been able to find something in the kitchen, only to have someone else pick it up right in front of you?
Step 6. When all else fails… start over.
Yes, this sounds extreme, but sometimes it must be done. If you have properly followed all of the above steps, this is very unlikely to be necessary, but if you find yourself stuck with no hope, starting over is usually not nearly as bad as you think it will be. Since you have already done it once, it often goes very quickly, and the end product is always better than the first draft was to begin with.
If you do have to start over, the second time around be sure to follow the steps mentioned above, and just consider the first go-around a learning experience. “Victory is sweetest when you’ve known defeat.” Malcolm S. Forbes
More troubleshooting tips?