99 Problems And They’re All In My Code
I consider myself to be brave.
I’ve hiked mountains, I’ve swum in murky waters, I’ve gone to the movies alone, and I even walked into my grandmother’s house with my new tattoo on full display.
But something about the console lighting up in red makes me want to run in the opposite direction and do anything, anything to avoid sitting at my desk.
There are problems that politely walk up to your door, knock, and request to stay for tea and be addressed. These problems might need a cup of Earl Grey with two sugars and a splash of cream, followed by a lightly warmed scone, but once we offer time and nourishment, they go on their way.
Then there are problems that crash through your ceiling, tell you that you won’t be sleeping anymore ever, and that they want all of you and everything you have right now. They don’t just request attention, they demand your blood sacrifice. These problems overwhelm your senses and leave you paralyzed, unsure of which direction to turn first because every direction needs something.
This is what debugging feels like to me.
Seeing an error in the console makes me feel personally attacked, like doesn’t my code know what we’ve just been through together? Weren’t we on the same page with the same plan? Et tu, Brute?
Learning how to step back and analyze the messages my code was giving me was it’s own entire series of therapy. If you also find yourself slowly backing away from your code in a panic, then get comfy and keep scrolling because you’re in good company. Below, I share six ways to find and handle bugs in your code.
Ask yourself the million dollar questions
The absolute first step when approaching a problem is to know what you wanted to happen and then discern exactly what is happening. First, what did I expect my code to do? Second, what did it do instead?
Look for typos
I cannot tell you how many times my code has broken because I forgot an “s” or an underscore somewhere. A thorough, line-by-line scan, just to make extra sure that you didn’t misspell anything is crucial.
Console Logging/Printing
Every programming language has a method for printing a message to the console. Follow the path of your data by giving yourself sequenced messages throughout your code. Including descriptive strings of text in your console logs will help you read your console more clearly. For example, console.log(x, “x”) will give you a point of reference, but console.log(x, “here I am for the first time”) and console.log(x, “here is where I ask for tea”) makes your console a lot easier to interpret.
Commenting out lines
When you’re unsure which line of code is causing you trouble, start commenting out lines, to narrow down the scope of possibility. It can be difficult to see if your function is returning the value that you want. Commenting out lines and then returning a console log are great tools to use together.
Debugger
Debugger stops your code in it’s tracks, to show you exactly what a variable’s value is. It will allow you to move backwards, forwards, and even two-step, to visualize the path of your data. It’s more complex than other methods, but extremely beneficial.
Testing
Test, test, is this thing on? Tests range from simple to complex. They’re an automated way to ensure that you haven’t done anything by accident, like introducing a new feature, but breaking another on the way. Having standardized tests that exist between development and production allow you to know when you’ve broken a feature, before it gets sent to production, and should be included in any deployment process.
Problematic code does not need to be a crushing weight. With the right teas on your table and tools in your pocket, sitting down to work through errors becomes much more manageable. Just take it one line at a time.
