How to Solve a Software Bug FAST

[ @todo: Insert photos of bugs and fun stuff.]

It’s not always important to solve bugs with great speed.  In fact, “slow down” is a tip I give myself regularly.  BUT, it’s true that I’ve figured out some favorite techniques that help me solve software development bugs in a timely manner, and I hope you find something helpful here!

#1 Read the bug report carefully and ask questions.

Most initial bug reports don’t have all of the important details.  Ask questions so that you don’t lose time going down the wrong road.  Well thought out questions show that you are working on the issue, which is good news to anyone who cares about it getting fixed.

#2 Reproduce the bug, ideally on your local development sandbox.

You’re going to have to set up the bug locally anyway, in order to test your fix, and my advice is to make reproducing it locally something you do very early on in the debugging process.

The process of trying to reproduce it may shed some light on the situation, which helps with knowing what questions to ask (see point #1).

I have an approximately 2000x greater chance in fixing a bug I can reproduce than in fixing a bug that I can’t reproduce.

#3 Ask for Help

If the importance is on the speed on which the bug gets solved, then the more brains, the better!  How soon you should ask for help probably depends on the seriousness of the issue, and your likelihood of solving the issue on your own.  Be honest, do you have the technical knowledge here?   Have you solved other similar bugs before?

There is no shame in not knowing something.  Often it is just a matter of experience, which you will gain in time.

#4 Watch out for the Wild Guesses

The reason not to ask for help, is that sometimes people will help by giving suggestions that could not possibly be correct.  Be careful!

I only consider answers which “could not possibly be correct” after I’ve already checked out the technically most likely causes.  Don’t go down a rabbit hole that’s a 1 in a million chance.  (On the other hand, don’t assume that you have superior knowledge, and be careful to not dismiss a suggestion just because you don’t understand it.  Ask questions.)

#5 Define the scope

Software systems are HUGE!  Let’s make the haystack smaller…

If this is a website bug, does it still happen with Javascript disabled?  That’s a good way to tell if it’s a backend or frontend issue.

If you disable a plugin/module/theme or otherwise remove some included files, does the bug go away?

Another way to define scope, is to use a debugger and put a break point before and after where the bug exists.  Examine what happens to the relevant variable values until you can be certain of the code block where the error happens.

#6 Assume it’s a recent change.

Did you do something recently?   Look at your recent commits, software updates, etc.  If this is a huge problem that did not exist before, something must have changed to cause it.  You can also check out previous git commits/other git branches and see if the bug existed in them.

#7 Stay Focused; Put the “Emotions” aside.

Has this bug caused your adrenaline to shoot up?

Or, has it caused others to stress?

Try to put all of your feelings aside, and follow a process driven by logic instead.

I find that understanding emotion is very helpful when interacting with people, but computers don’t care how I’m feeling.

YOUR emotions, as well as the emotions of OTHERS can interfere with your ability to use reason to solve an issue that’s logic based.

Do what you need to do in order to stay focused on solving the issue.  I (try to) banish my emotions to the other room.

What you can’t control

In the past, I have tried to rush things that I want, and in doing so, I miss the enjoyment of the journey there.

And even in that statement, I am failing to correctly describe the concept.  It is a mistake to assume that I can control the destination.

One of life’s greatest struggles is in accepting that some things are out of our control.

I like control.

You’ve got a problem?  I’ve got a solution.


But there are some things we can’t control.  In programming we wrap them in “try…catch” blocks.

We only have control over the “try…” part.

Adding Node.js to my skillset

Learning Node.js has been in the back of my mind for awhile.  It’s an in-demand skill, and its event-driven nature seems perfect for some ideas I have.  Plus, all of the cool people are writing node.js.

A few weeks ago, the right forces came together to convince me that I should write a node.js app.

Writing a program is my favorite way to learn a programming language.

But to say that I learned a new programming language is not really correct here.  I already knew Javascript.  I even already knew some ES6 (ECMAScript 6 Javascript) from work.  And, I’ve worked with npm modules in the context of frontend build systems, so I already understood some of the concepts.  (If this sounds like you, then I would say, “you, too, can learn node.js!”)

Spoiler: It was easier than I imagined.

Just to fill you in, I’m a Php developer who finds herself in Javascript code 10% of the time.  Recently that percentage is starting to increase.  And, I’m even starting to like it… To understand it.  With understanding, there becomes desire to understand more… And I notice that some of the best developers at work are strong php and strong javascript developers.  Javascript is no longer just for frontend devs.

With all of these thoughts stirring in me, and the boring winter months approaching, I decided to write a node.js app on the weekends.

What I Wrote

Watching my node.js app run!

I wrote a middleware app which polls a server for some data.  It then validates the data with the Amazon product advertising API, and then updates a mysql database (basic CRUD actions).   The app runs continually and polls for this data at regular intervals.

This turned out to be good practice because I was able to make use of Node’s events and promises.  I had to batch the validation process, since you can only lookup 10 items at a time.

The good news: the app was complex enough to create some bugs, and I found myself debugging the app in phpstorm.  Setting up the debug configuration for a node.js app in phpstorm was super easy, and I was soon presented with the familiar debug panel.

Debugging Node.js App in PhpStorm

Learning Resources I Used

I started by reading the Node Beginner and the Node Craftsman books by Manuel Kiessling. These books appealed to me because they’re aimed at developers who are familiar with other server-side languages like php, phython, or ruby.

Next, I did a bunch of googling and reading and figured out that I could write my app using ES6 classes.  Yay!

Finally, once I got my app working, I realized that I needed to learn about deployment.   I decided to use systemd to run my app as a service.  The following resources were helpful:

Deploy Node on Linux

Running your Node.js App with Systemd

Deploying Node.Js Apps with Systemd

I know those last 3 links sound similar, but I do recommend reading multiple guides when approaching an unfamiliar task.  In this case, each one added a bit and between those and stack overflow, I got it figured out.  I got my app up and running on ubuntu!

Interested in working with the Amazon Product Advertising API?  Try “npm install apac”

My thanks goes out to the developers of the apac npm module. This module is a thin wrapper for Amazon’s product advertising API.  If you are familiar with the API, you will likely find that module easy to work with, as I did!