[jchw]

I do not use a debugger most of the time either. Let me tell you why I don’t:

- Because I forgot how to use it (or never knew how.) There are many debuggers and UIs and I still know how to use some of them to decent effect, but I simply don’t know how to be effective with most of them.

- Because I’m pretty confident I have a good understanding of what code is doing nowadays. My intuition has been honed over the years and I tend to quickly guess why my code isn’t working.

- Because my code is all unit tested now. This contributes to my ability to be more sure about what code is actually doing.

There are still some cases where I may try a debugger. I had one recently where I was unsure what path my code was taking and I wasn’t sure how to printf debug. That helped a lot.

Not using a debugger is not really a choice I made or something I do to try to look impressive, rather it’s most likely a result of the growing diversity of programming languages and environments I work in, combined with better testing habits. I just feel like I have enough confidence to fix the bugs quickly. When I lose that confidence is when I break out printf or the debugger.

[scarface74]

Because I’m pretty confident I have a good understanding of what code is doing nowadays. My intuition has been honed over the years and I tend to quickly guess why my code isn’t working.

So does your code ever use other libraries? Does it ever call third party APIs? Do you ever have to modify code you didn’t write? Do you remember what your code does that you wrote 10 years ago?

[jchw]

Surprisingly, third party libraries have ended up being fairly predictable as well. Not perfectly, but enough that I am usually not too concerned about it. Tend to RTFM at least once, though.

[scarface74]

Try reading the manual for Boto3 and writing code blind without being sure of the response format without just calling it first and looking at the response.

https://boto3.amazonaws.com/v1/documentation/api/latest/inde...

[jchw]

This may surprise you, but I don't use Python or boto3. Last time I used either of those was nearly half a decade ago. Software I use nowadays generally has much better documentation, not to mention is written in a language where I can get code completions and accurate typings.

Also, I never said that I don't read the source code of third party libraries. In fact, I do. I like to embed third party libraries directly so that I can inspect them inside of my workspace. For almost any library that I use, though, it hardly requires much familiarity to get basic operations working. Since a good amount of the libraries I use at my day job are proprietary, I can't just google for Stack Overflow questions and sometimes documentation isn't always available, so it would be pretty debilitating if I needed a debugger just for the simple task of utilizing a library.

This is also part of why I stopped using Python. MyPy shows promise, but without typings at least on par with TypeScript, my productivity in Python was surprisingly poor despite amazing frameworks like Django and DRF. Simply put, there was almost always too much futzing around, and even with many debugging techniques I sometimes never fully figured out what was wrong with my code.

[scarface74]

I used Boto3 as a large complex library that you aren’t going to inspect every line of code. But you mentioned web development, so you inspect every single line of every third party dependency? Every library?

[jchw]

Nope, just when necessary; usually I don’t read very much of the code. Intuition, comments, unit testing and editor help does the rest.

Well designed APIs are self explanatory.

[stock_toaster]

What languages (and industry) do you work in these days? Genuinely curious.

[jchw]

For the most part, C++, Go, TypeScript. At work I mostly write (micro) services or web UIs, and at home I do whatever (Tetris clones, small studying apps, utilities for reverse engineering, I’ve even done a couple Gameboy emulators in Go.)

[ben509]

That's been my experience in recent years; unit tests eliminate a whole swath of bugs that I'd otherwise use a debugger for.

And beyond the bugs themselves, reading the unit tests shows me what a function is expecting and what it's doing, and especially its behavior in edge cases.

The other technique I use is judiciously placed assertions that enforce invariants. I'd rather the system fail explicitly than have it returning junk data to users. (I work in finance, so customers are far more forgiving of a system returning an error message than seeing their balances be mysteriously wrong.)