4

Sadly took me a little longer than I’d like to admit to go from well placed print statements to using a debugger. Granted there are times when print statements are needed, but for all the devs out there who are using an IDE with a perfectly good debugger and yet doesn’t use it... please use it. It literally gives you a mapping of all objects and data types around a break point that you can easily glance at to speed up debugging. Go figure!

Comments
  • 0
    I mostly don't need a debugger because I can read the source text. Actually, a big danger of getting into the debugger habit is people who need to run their programs step by step in order to understand what they have been coding, and then interactively fumble around with it until it seems correct.

    Also, these people are completely helpless when being confronted with only vague error reports, but no clear instructions how to reproduce the error. Yeah, in FOSS, devs will often just close the PR with "works for me", but customers who pay real money simply don't accept that.
  • 0
    @Fast-Nop Im no developer but I’ve used a debugger before and that’s seems harsh. Maybe in work you wrote or with few authors that makes sense but my immediate response is “what if I’m debugging code I didn’t write and haven’t had time to become familiar with it yet”
  • 0
    @Fast-Nop There’s step in’s and outs of function domains that debugger gives you. So you can literally follow exact execution of your program... the debugger gives you a viewing of all data structures around your breakpoints to see what’s in them... don’t see how that’s not useful? As I said in my post it’s not a one size fits all and there are cases where print statements are needed but come on, a debugger is extremely useful. Who doesn’t look at their source code to understand workflow haha? That’s the first thing you should be doing. Debugger is more for runtime data analysis to see if things are setting properly or if execution is happening right. I don’t really use it for the error reporting because my exception handling should handle giving me proper feedback in that regard. Just my thoughts.
  • 3
    @Diactoros I often have that at work with code I didn't write and where the author is not even in the company anymore. Read the source, Luke.
  • 0
    @dalastTomCruise The last really nasty bug would have been way over the head of any debugger junky because we didn't even have a test case. Actually, all our test cases had been passing. Only some vague bug report, that was all.

    In order to even devise a test case, I had to find the bug first. Basically a combined hardware/software race condition that would only occur with a specific input permutation in a specific timing, and even then only in like 1% of the cases.
  • 0
    @Fast-Nop yeah I get you. There are quirky conditions where a debugger will only mislead, but for the most part it is quite useful for tracking behavior or understanding data. I agree that a developer shouldn’t be too reliant on just one tool either. The point of this post was to encourage devs who rely on print statements everywhere to try a different tool that could save them tons of time.
  • 1
    @Fast-Nop like the Star Wars reference btw :P
  • 0
    @dalastTomCruise well the truth is, you won't be able to debug such a very nasty error scenario by carefully reading without years of training in finding simpler bugs that way.

    I had a colleague showing me some intricate code he wrote as bug fix, and after 10 seconds, I told him this wouldn't work. He asked me why, and I couldn't answer, it just didn't feel right. Took me half an hour of analysis to actually prove where it would go wrong, but I had that feeling immediately.

    That's something that you can get if you take the hard way. Intuitive programming.
  • 1
    @Fast-Nop yeah seems like you’re talking about situations when multiple threads or applications may be trying to access the same resources. Debugging can be tricky there... I feel like the intuition comes naturally after programming for some time. It’s like you’ve seen enough patterns and errors to use as a heuristic to pinpoint what’s happening faster or if something will work in the first place.
Add Comment