Commute talk: Why I don't use a debugger

Questions? Topic suggestions? I'll happily talk about anything. Drop a comment below :)

[razielhamalakh]

Different tools for different jobs. Prints help pinpoint where and what went wrong, because you get a lot of relevant information fast. Usually that's enough. But when even then you go "wait, what _exactly_ is happening here?", that's when you pull out the debugger — and you have a smaller target to debug. It's slow, but deliberate and precise. Like a blunderbuss vs a sniper rifle.

[fuhrtygffhbhs]

I learn a lot from you every-time i watch you on the commute and live sessions.

[jonskunator]

There is a "locals" feature in Visual Studio which shows the values of the variables in the current scope. When combined with breakpoints, it can be quite handy. Something between printf and a classic debugger.

[MrDukeeeey]

I use printf debugging in my code a lot. One advantage is you can watch values/events change in real time without stopping the program. Sometimes if a problem happens it's easier to print 100 lines then attempt to step through a function 100 times. That said the debugger is absolutely invaluable. Having the ability to put a break point anywhere and look at the memory contents and step through each line of code to verify it is at least working as expected is invaluable. I can't imagine living without it.

[Pracedru]

I agree with this.
Also browsing through the data visually in a debugger with the mouse is often slower.

[MrCAJunior]

Nice to see you talking honestly about it. You took away the 'pros has to use debuggers' feeling from me.

But I discovered frida-tools recently, and I think its perfect for printf debuggers like us.

Peace!

[enque]

Nobody in the comments mentioned how working with tons of different languages and also working with embedded hardware trains you to rely on the print statements instead of a debugger. So I want to add it.

Because there is no debugger that works in all tools, languages and all IDE:s so after a while of jumping between them you finally get so annoyed over not having immediate access to the debugger function you need, that you train yourself to use print statements instead. The same is true for embedded hardware. Ok so I need to find a bug that only appears in the finished product and not in any of the pre-merge tests? Ok fine I'm gonna "print" statements as voltage levels to these three GPIO pins and view it with an oscilloscope. Boom I solved the issue before my colleague even finished hooking up the debugger properly.

Print statements all the way, baby!

[CrippleX]

I remember using print statements in php because debugging php reeeally sucks (or at least, it used to - haven't used it in years). I must say it got me quite far but I must say that after stepping over to "real" programming languages, using a debugger to get insight into the state of a program at the point where it crashes has really helped me to fix bugs. I've found that a debugger can provide so much more information than a print statement ever could and the ability to step forward, into etc. is very helpful.

[antoniocs]

A combination of both is what suits me best. Trying to understand the program, I'll use print statements but then when I want to see the contents of variables (without the printing them) I'll use a debugger

[limitless]

Really apprecieted for making this video.

[manuelnovella]

I once got the opportunity to ask Richard Stallman how could he manage to program everything he has programmed (it's literally a whole lot of tools) and, funny enough, he told me the most important is to learn how to use a debugger. But I honestly think you're totally right in using what fits you best. Tools are just there to be used if necessary, not otherwise.

[forgottenmohawks]

I feel the same way, somewhat :) I still sometimes go into the debugger, but a lot of the time it is just much more flexible and effective to throw in some print statements.

[human-ftwk]

It's crazy that I use the debugger and I find it really boosts my productivity a lot. And I was going into this video slightly afraid that I shouldn't use the debugger :)) Much like your situation with print statements but flipped.
Yeah, I suppose different people resonate with different tools

[JannisAdmek]

Great commute talk! I personally use print-statements when I want to see the flow (what executes when) and the debugger when I wanna see lots of variable states.

[AtmoStk]

What a coincidence. It hasn't been that long since I switched to using gdb over print statements. Since my projects were starting to get bigger, I figured I should try to be more "professional".

[simpleprogrammingcodes]

I agree. Now I notice that I could catch some bugs I would have never been able to find without printing. For example if something occurs randomly from time to time, you have to be able to isolate what leads to this condition. But if you use a debugger, if you go through 100 loops and catch this condition once, you caught it only one time. You cannot generalize.

[Quaker]

I'm starting to subscribe the "printf debugging" philosophy also. Using QEMUs GDB stub has been somewhat of a nightmare. Good piece of soctware, very application/use specific :)

Very true with needing an understanding the workings of the code/program itself before you can even debug. There's no point stepping through without (as you said) a mental model of *how* it works in the first place.

[samuellourenco]

My favorite debugger is printf() as well, but that is probably because I don't know better. Nevertheless, it is a superb way to check what is being written to variables, as long as the code is rewritten as intended once the tests are done. I've had to do this extensively to test the last version of my cp2130-qt class. It is very important to check if the USB descriptors are being correctly written before configuring an actual CP2130. OTP ROM is expensive. ;)

Anyway, I really enjoy your programming skills, and you are on a completely different level. I wish I had your skills. You are a natural. I can see that coding it is effortless to you. It is like seeing Mozart composing a superb piece at the last minute (he actually did that).

[matttepp]

It's great to know I'm not doing something wrong by not using a debugger, I just always felt way more comfortable printing everything out.

[MindGameArcade]

Crazy to see this pops up on your channel, I was thinking about this exact topic some times ago. I think you are right by saying that you should use whatever makes you feel more productive. However I'm personally a big source code guy, and I believe that it is the best practice "in general" let's say. I don't use print statement until the last second and very rarely use the debugger. My current experience is that it is more effective.

It is as you said, reading the source code builds up actual knowledge. You understand the true *intent* of the program at every level. What did the guy want to do, what is he actually doing, at a high and low level.

Whenever I see a programmer use a debugger he gets completely lost in meaningless details, doesn't know the code surrounding what he is looking at and doesn't understand where it is going. The logic, the intent is hidden. And very often, the debugger guy will fix the technicality, it's like a dirty patch. The source code and print statement guy will actually fix the fundamental design flaw of the program. The source code guy actually has the ability to re-write an entire program, completely different source code, but doing the actual same thing at a high level.

Currently I actually don't really see a point in debugging, the only true cases I can think of is absolute urgency, when you need to patch something extremely fast. And even then it could be super dangerous. You can make it run, sure. But maybe it's doing complete garbage now. Or when you lack low level knowledge of the language and want to see where it is going, maybe.

I would like to hear some arguments about when you should use a debugger because my current practice, which I believe to be the best, is to read the source code a lot. Understand the intent. Then do some small "unit" (or whatever, an executable using the source code) tests around the thing you want to debug until you find the true reason of the bug. Not only the bug itself, but also how it came in the source code. Inexperience from the programmer? Design flaw of the language which makes everyone do the same mistake? Etc, etc. Why the bug was introduced to the source code; So that I fix the bug, but also prevent it to happen in the future. Ultimately even if you debug you'll have to go in the source code, why not start there.