Posts tagged 'debugging'

Helping juniors debug

published on June 23, 2016.

These days I spend most of my time reviewing code. Lots and lots of code. It’s mostly written by juniors and some of it is good, some of it is bad. I try to be patient, to be a good mentor, to hopefully teach (and be taught), while not letting out of sight that the most important thing is that the code does the right thing in the right way. The business and the users come first, after all.

When I encounter a piece of code that looks like a bug, I run the code myself to verify it. After that I usually ask a short question, something like “Hey, what does this code do? I think there’s a bug in it”. There are times when the author figures it out on their own and fixes it, or asks for help. If the former, great, if the latter, I either give them some time to figure it out on their own, or help them debug it — depending on the difficulty of the bug.

What I don’t do is outright tell them what the bug is, or even worse, how to fix it without giving them the chance to understand the bug. How are they going to learn like that?

Granted, guiding them through the entire debugging process can be slow and difficult, so this might not be a good approach when the deadline is close.

I do believe that taking the time to guide them can be rewarding for all parties involved. They get to learn by doing, get an insight on how a more senior developer works and thinks, and I, the very least, get to improve my communication skills by being forced to explain my thought process in words.

What are you trying to do?

That’s usually my first question. It’s important to understand what they think is going on, so I can guide them better. It also prevents me from assuming they know something that might be fundamental knowledge for a senior, but not so much for a junior.

My end goal is not just to fix a bug, but to actually teach, help them understand what is going on, so the next time they can fix the bug on their own, or prevent it from happening in the first place.

What does the code do?

Next thing I ask for is an explanation of the code, line by line if needed. This is probably the slowest part of this process, but I think it is necessary as it can point out places where their knowledge is lacking. They might don’t understand a language feature, misread how an internal API method needs to be called, think that the code does one thing, but actually it does something else, because hey! that’s how it works. And we’ve all been in a situation when we misunderstood something. It’s OK. Our job is to teach them, just as we were taught.

During this part I try to not interrupt them, I let them finish. I keep track of all the bits they got wrong and go back to those one by one once they are done with explaining the code.

Again I try not to flat out tell them what they got wrong, but to guide them to the correct answer. Asking simple questions like “Are you sure that it’s doing what you think it’s doing?", or “Have you read the manual entry for that method call?” can be at times enough to make them see their mistake. “Oh, I’m passing a string and it should have been an array!” (side note: PHP 7 can’t come soon enough to all of our projects).

If they just don’t know what they got wrong, explain it to them. Don’t try to skip over any parts that might seem obvious to you — it might not be so obvious for them.

Rinse and repeat for all the parts they got wrong.

Let’s find that bug

Now when they have a better understanding of the code, ask them to find the root cause of the bug. I repeat myself, but guiding them to the moment of discovery is much better than just leading them straight to the answer. Let them have their “A-ha!” moment. I know those moments are the best moments for me.

At this point they should be able to tell you what be a good fix for the bug. If it’s a good fix, great. If not, ask them something like “Do you think doing X would be a better approach?” and explain why it would be.

This is a long process that can take up quite some time, even up to an hour or an hour and a half. You’ll probably need to do it more than once because, well, there are many types of bugs and not all bugs can be debugged the same way, but it is going to be rewarding for both you and the junior. And the more you do it, the faster it will be.

Until one day when they will be teaching the next junior on the team how to debug.

pugdebug 1.0.0.

published on July 01, 2015.

After 3 months since announcing that I’m working on pugdebug, and some 5 months since I actually started working on it, it is finally time to let version 1.0.0 out in the wild.

It’s been a busy 3 months: 82 pull requests got merged, 67 issues resolved, more than 350 commits pushed. A lot of changes, fixes and improvements found their way into this first version.

First of all, a big thanks goes out to Ivan Habunek and Srdjan Vranac for helping. They asked for and added new features, tested on Windows and OSX systems, helped fleshing out ideas.

One of the biggest news is that there are binaries built for Linux and Windows operating systems, using pyinstaller. These binaries include everything pugdebug needs to work so there is no need to install anything. Just download the binary for your system and run it. That’s it. It makes me incredibly happy that it’s possible to have it this simple to run and use pugdebug.


The user interface has improved a great deal. It is using dockable widgets for different pieces of the UI, making the layout of the application configurable by just dragging the widgets around. It’s not all great though, there’s still room for improvement, but it will be better over time.

pugdebug allows to debug multiple requests one after the other which helps debugging in a more “complicated” scenario where there are, for example, multiple AJAX calls triggered in succession. By starting to listen to incomming connections, pugdebug will listen to all incoming connections and, based on the IDE key setting, decide should the connection be queued for debugging, or ignored.

It is also now possible to create projects inside pugdebug, as a way to help switching between different PHP projects where debugging is needed. Simply name the project, set it’s settings and that’s it. pugdebug stores all the configuration files in it’s own directory, so nothing will be added to your PHP projects.

I’m especially happy and proud that pugdebug got included on Xdebug’s website on the list of remote debugging clients. Thanks to Derick Rethans!

For more information on how to use pugdebug, take a look at the read me file or the wiki and let me know if you have any issues with it!

Introducing pugdebug

published on April 01, 2015.

In my spare time in the past few months I was working on a tool that would help
me in my every day job as a PHP programmer. As you may, or may not, know, I’m
using vim as my editor/almost IDE, but one thing that is missing from it is the
ability to debug PHP files remotely. Yes, there are a bunch of plugins out
there that add debugging to vim, but none of them felt usable for me.

And based on my google searches, there are no standalone remote debuggers for
PHP, that work on Linux.

In February this year I started to work on a desktop application that would help
me address this issue.


pugdebug  is a PyQt desktop application meant to be used as a remote debugger for PHP,
that communicates with xdebug.

It is meant to be a debugger and only a debugger. There are a plenty of (good) IDEs
that include remote debugging and I’m not going to start writing another one
(although I did start one, once).

The application is still pretty simple, ugly as hell, but it works. Sort of.
There are still a few kinks left to sort out and I’m doing my best to
write them all down.

It’s dependencies are Python 3.4, Qt 5.4, SIP 4.6 and PyQt 5.4. The
read me file
should have a bit more details on how to start using it. I know it’s a bit messy
to set everything up, but I am working on building executables for different
Linux distros. That stuff is hard!

It is lincesed under the GNU GPL v3 license, because PyQt.

Using pugdebug

Start the application, click the start button and then it waits for incomming
connections. Load a PHP page to start a
HTTP debug session,
and pugdebug should break on the first line of your code.

Stepping around the code is possible with the step into, step out and step over
commands. At each step, pugdebug will get the current variables state from xdebug
and display them.

Double clicking on lines in the code viewer will set breakpoints on those lines.
Do note though that there needs to be a debugging session active to be able to
set a breakpoint. This will change in the (near) future.

And that’s about it. While I know it doesn’t look like much, this was, and still
is, a nice learning experience for me and the best part of it is that I was using
pugdebug earlier this week to debug a PHP application I’m working on.

Xdebug is full of awesome

published on January 30, 2012.

I’m currently trying to fix a Mockery bug and, while deep in the code, I came across a piece of code which gets eval’d. Mainly to understand better what’s going on, I wanted to step debug it. I first set a breakpoint before the eval call and then tried to step into the eval’d code, but that didn’t work out, Netbeans just moves along to the next line.

What did work, is setting a xdebug_break() call inside of the code that will be eval’d - and BAM! it works! Netbeans picks up the signal and everything works just as with regular code - you can view the values of the variables, step in, step out and step over code.

Xdebug is full of awesome.

Happy hackin’!

Tags: debugging, xdebug.
Categories: Development, Programming.

Debugging two PHP projects in Netbeans at the same time

published on August 19, 2011.

I’m currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. The bundle files are completely separated from the app and they are just linked (ln -s) together. It works great, except for the case when I need to debug some part of the bundle’s code with Netbeans + xdebug. The debugger starts for the “main” project, which is the Symfony2 app, but setting breakpoints with Netbeans (y’know, by clicking the line number) for the bundle doesn’t really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The solution is pretty easy actually: instead of setting breakpoints with Netbeans, use xdebug_break() where you want the break to happen and it will happily be caught by the IDE. After the break happened use the “Step into” (F7) functionality to see what’s going on.

Robert Basic

Robert Basic

Software developer making web applications better.

Let's work together!

I would like to help you make your web application better.

Robert Basic © 2008 — 2020
Get the feed