Developers use different systems for working bugs. Some use the compiler and debug system to 'walk' through the code step by step and capture the point in time the issue occurs. Others dig into the existing code and create a logic chart of some sort to track what is happening. Myself, I use a combination of the previous two, but usually throw in some Log messaging to see what the results look like. It is an old school programming technique, where we had to rely on log messages a lot more than we do today with the fancy development environments. I like it, because I can turn the logs on/off when I want to see more detail in how the program is acting. I also find at least one part of my data layer that could use a bit of polishing to allow it to display the important information easier. This helps later when you revisit the code for a different bug.
The best part of coding is seeing the results of an idea form and display on the screen or device. Logging data or logical points in the code is also a part of this fun. You dig into the code, add your display hooks, and then watch the magic unfold as you run tests on the program. This is not always necessary if the code you are working on is fresh in your head, but after switching to 1 or 2 different projects, you can find your old familiar code is looking a bit foreign. Sometimes turning on the logging is just the jumpstart you need to get your head back into the frame of mind you had when you created the program. I also like the pretty print outs.
Coding is as much about a concept and design as it is about using some sort of language to implement that design. The little feedback loop that logging or tests on the code provide are the 'pellets' that keep the developer going on the project. "Yeah, that worked! So what is next?" The logical thinking and analysis is much like working a logic puzzle or figuring out a crime scene from the clues. Only in this case, I was both the victim and the culprit.