top of page

The Debug Trail

When mentoring I often find students whose code "doesn't work" and are lost about where to start fixing it. In particular I'm talking about when there's no error message. Rather, the code is just not doing what you want it to do.


My first tip is to ask yourself: "what did I change recently?" If that can easily help you find the issue, then do that. Otherwise, it might be time to hit The Debug Trail.


What is The Debug Trail?

The Debug Trail is how I find bugs when code is breaking down when trying to perform a task. Particularly when the task involves many parts of the code. Let's look at an example.


Let's say I have a Delete Post button in my list of posts in my app. When I clicked it, I expect the post to disappear. But when I click the button, the post doesn't disappear! And when I refresh the page and it's still there!


The first step of going down the Debug Trail is to define the path we expect the code to follow, step-by-step. That is, what should our code be doing?


For our example about here's what should be happening:

  1. A user clicks the Delete Post button

  2. An onClick handler for that button is called

  3. The onClick handler calls a function that makes an HTTP request to our server with that post's ID

  4. Our server receives that HTTP request

  5. Our server routes that request to the handler we have for deleting posts

  6. Our handler deletes that specific post

  7. The server responds to the client

  8. The client updates the page to remove that post

This is our trail. Now it's time to use it to find our bug.


What do we do with the trail?

The point of the trail is to go through it from one end to the next, and eliminate parts of our code as suspects. A mistake I see some new coders doing with a bug like this is is to just start changing everything. They'll make a change to the onClick handler, then make a change to the database query, then make a change to the route handler, each change bearing no fruit.


Instead, pick an either the start or the end of this trail, and go through it, eliminating steps as you go.


For our example, I would start at the beginning of our trail. Whether to start at the start and go forward, or at the end and go backwards, will change from bug to bug and project to project.


Eliminate some steps

Here is what I would do:

  1. Go to the page causing the issues in my browser

  2. Open up the Network tab of the developer console

  3. Click the Delete Post button

If I see a request is to the server then yay! I've just eliminated steps 1-4 of my Debug Trail. I can move on in the trail. I don't need to spend any more energy thinking of that part of my app. My focus was just cut from 8 potential problem areas to 4.


Continue down the steps

Now you just continue down your Trail, eliminating steps as you go. Here's a breakdown of you might do that for the remaining steps:

  • Step 4: Is our server receiving the request? Check the logs of our server. Maybe the frontend is making the request to localhost:8080 instead of localhost:5000?

  • Step 5: Is the right handler getting the request? Is the request responding with 404? Maybe put a console log in that handler and confirm it's being called.

  • Step 6: Is the handler deleting the right post? Are there any errors coming from the database? Maybe console log the id of the post it's trying to delete?

And so on. The point is that each time I check one step and move on to the next, I'm narrowing the potential areas the problem can be. The bug can feel me approaching, zeroing in. Stay on target! Stay on target! STAR WARS.


Eventually you'll find the problem area and it will be easier to squash the bug. Happy hunting!

bottom of page