Software, Development, and WordPress

Why You Should Learn Your Debugger

I’ve talked a bit about debugging (using an actual debugger) in a few posts, but I don’t know if I’ve ever talked about the challenges that come with debugging.

Learn Your Debugger: MacGDBp

MacGDBp is one of the available debuggers.

First, in this context, debugging refers to using an actual piece of software versus various language features. Secondly, using a debugger has its learning curve just like any other piece of software.

And in this tweet, Julia Evans captures it perfectly:

Not bad, right?

Learn Your Debugger

For those who have yet to take a deep dive into debugging, there are five key things to understand that all debuggers implement.

  1. Breakpoints. These are places in the source code that you mark that tell the debugger to stop the execution of the source code. Think of them as a good place to start when you’re suspicious that there’s activity near this point in the program. Think of it as pressing pause on some media.
  2. Continue. If breakpoints stop the execution of the code at a given point, then continue is its counterpart in that it resumes the execution of the source. It’s like pressing ‘Play’ after you’ve paused a video or a song.
  3. Step In. Say that you set a breakpoint at the point where a method is called. A step in will allow you to step into the function that it’s going to execute so you can trace the code line-by-line to examine variable values and other things that are set at that point in time in the program.
  4. Step Out. During debugging, you may find yourself in a function that isn’t yielding any results regarding actually finding a bug. If that’s the case, then there’s no reason to stay in that method. So, at this point, this is where you’d want to step out of the function and back up to the last line you were before stepping into the function.
  5. Step Over. Let’s say that you set a breakpoint right above several method calls, but you don’t care to step into each and every one of those functions. Instead, you might be interested in just stepping into one of them. Stepping over a line of code will still let that code execute but saves you from having to go over each line ultimately saving you time while also allowing any relevant values to still be set (and viewed) within the debugger.

When trying to learn your debugger, learn these features first. From there, some debuggers will offer advanced features (some, but not all).

And if they do, then you can move forward with learning those features.

But if you take these five features to learn your debugger, then you’ll be able to take nearly any debugger worth its weight and be able to work within any environment.


  1. Damien

    What are the debugging options on shared Unix hosting (no SSH access) and Windows desktop?

    Am I likely limited to error_log()?

    • Tom

      What are the debugging options on shared Unix hosting (no SSH access) and Windows desktop?

      That’s tough — normally, remote debugging is required and this is only available if you have access to change the php.ini configuration on your server if it’s not already done for you.

      Who is your host?

      Technically, you shouldn’t have to do a lot of remote debugging if you have your development and staging environments set up exactly as your live environment.

  2. Carl Alexander

    Love that image! And yeah, I’m one of those weird people that like fixing bugs. You always learn something and it’s always a humbling experience (even if it can be frustrating at times)

    • Tom

      Love that image!


      I’m one of those weird people that like fixing bugs. You always learn something and it’s always a humbling experience (even if it can be frustrating at times)

      I like fixing bugs in that it feels like the app is cleaner and more robust (plus you learn something, usually, each time you do).

      But yes – it’s both frustrating and humbling because you think “How could I missed this the first time around? Why did I do it this way?”

  3. Jon Brown

    That is a great comic. Have you ever thought of recording a screencast of you debugging?

    The reason is I hear all this talk of using xdebug, but I often find it’s just easier/faster to go old school with hand typed debug code, var_dumps, print_rs, etc… I’d love to see a specific real world walk through of a situation where a debug tool like this really helps (I don’t doubt they exist, I just don’t recognize them)

    • Tom

      I’ve considered it but it’d seem like it’d be something so boring to watch. Perhaps I’ll consider it again :). 

      Regardless, once you get a good debugger that integrates well with your workflow, it’s great to be able to hop over to the debugger and interact with the code versus constantly having to do page refreshes with the browser, var_dumps, echoes, etc. 

      Being able to see everything that’s happening “behind the scenes” is so much more powerful than those statements. It just takes some time to get used to and it takes a good debugger than fits in with your environment, imho.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑