Computer languages share many similarities while still being completely different from one another. Syntax varies greatly, as does the way variables are declared, in some languages you have to worry about scope, other's not so much. There is one thing though that all languages share, errors. Although all languages will kick back an error when something is off, not all errors share the same details. In Ruby, errors are extremely forgiving, they do a very good job at explaining what, and where things went wrong. Javascript's errors or not as kind, they don't assume the way Ruby does, making things a little harder to debug when inevitability strikes.
I'd like to share my though process, questions I ask myself, and approach on how I tackle any errors to debug:
Remember Your Training:
You started your journey into development by learning and studying the particular language you're writing. During this process you should have run into tons of errors. I'd like to say this is part of the developing growing pains, but in reality, errors are here to stay and are your friends, embrace them! Try to think about what the most common errors you received during your learning process. This is a great place to start, go over all the common errors you're used to getting back. You can start crossing them off of your debugging list and move on to the next step of debugging.
Think About Your Own Scope:
You should be working on your project in pieces and pushing to Git frequently! Some good questions to ask yourself: What code was working before the problem occurred? Do you have a previous working Git commit to compare with? Where in your code is it breaking and if you can tell, what block is causing it to break? Narrow down where it's occurring.
Weed Out The Necessary Info From The Error:
Many errors will kick back a ton of information, a good amount of this information will point to folders you haven't even been working in. There are situations where these folders being pointed to will be relevant, they have been few and far between for me. Learning to trim the fat off of these error messages will help cut down your debugging time. Most of the time the most important part of you error messages will point to a folder or block of code that you've written in your program.
Location, Location, Location:
While your error may not say explicitly what the problem is, it generally will point to where it's occurring or bring you very close to where it is happening. Some things to keep in mind, is your code that is breaking interacting with other code? i.e. Is it breaking in the front end while doing something with the back end (or the reverse)? Follow all the routes your code is taking and analyze every place it's making something happen, it is possible a backend problem is causing an error code in the front. Be mindful of this, maybe leave yourself some breadcrumb comments that points to what backend block is interacting with a frontend block.
Use The Tools Available To You:
Just about all languages come with some form of a debugger. Do yourself a favor and get acquainted with it early and often as it will be your best friend at times. Whether it's pry, byebug, or tools made available to you through Chrome's dev tools, be aware there are helpers out there to allow you to stop your execution and for a moment live inside the block giving you problems where you can call and run code related directly to where you stopped your program.
The Great Google:
The good news: the error you've run into has happened millions of times to other people and has been solved. The information on how to fix this is already on the web, waiting for you to come across it and have it help you.
The bad news: You're having trouble putting exactly what is happening into words when searching. Are you searching your problem in your own words? Did you search the specific error you're getting back?
There's a few things at play here. All coding projects vary greatly in what exactly it is the application is doing, this can make it difficult to apply what you're reading in your error googling to your own code. This is something that will come with doing more. More coding = more errors to read = more articles to google
Check With Your Network:
So you've made it this far, you've tried everything your brain can wrap itself around and you still have not fixed your bug. You've google, tried many different approaches, refactored your code, made a mess of things and still came up empty. Time to swallow your pride and ask an external source to come take a look. Sometimes there's nothing like a fresh set of eyes to look over your code and help. The same way walking away from coding can help bring clarity to a situation, a view from the outside in can help immensely.
Let's face it, bugs are annoying as hell, but they're not going anywhere and are a necessary evil. Embrace the suck, it will build you into a stronger coder. Sifting through bugs in great detail will help you out in the long run. Also, the more you do it the better you will become at it, practice won't make perfect, but it will certainly get you a hell of a lot closer to it.
Top comments (0)