I almost always start with thinking about where the bug is likely to be, then doing some print/log debugging to confirm or reject my suspicions. I find it pretty effective and simple to do.
Debuggers are complicated and create dependency. How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours.
I'll break out a debugger if all else fails, but it's not my first choice.
> How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours.
Er...very few? A bad programmer will be a bad programmer with a debugger and that bad programmer will be a bad programmer who prints out state after every line of code.
Breakpoints and watches are strictly superior to print statements for understanding the system you're working with. You drop a breakpoint where, as you yourself put it, "the bug is likely to be," you look around, you kill the process and you make a change. It doesn't "create dependency", it's just better at solving the problem. Anyone can fall back to println debugging if necessary. It's not some difficult thing. But it's wasting your time.
I find a good logging library will help me narrow down the issue before I enter the debugger to watch what the system is doing.
If I'm 90% sure I know what the bug is and it's a system where it's easier to add a print than to enter the debugger (yes, those types of systems exist), I'll do that first.
Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison (unless you've footgunned elsewhere). Whether it's something like `pry` in Ruby where you can open a REPL on command or a JVM where you connect with an external debugger, most systems are flexible enough to work with you.
If you've written something in a language where you don't have a debugger...that's your own damned fault. :-P
> Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison
It's often hard to run a stepping debugger when you have an embedded hardware
at hand. It's equally hard to run such a debugger when you have multi-threaded
code. And the same stands for virtually any system that works with network
directly, where timeouts are plentiful.
Also, good luck with a debugger in this modern architecture of microservices
that happens to be hype nowadays.
> It's often hard to run a stepping debugger when you have an embedded hardware at hand.
Totally true. But that's a pretty rare situation.
> It's equally hard to run such a debugger when you have multi-threaded code.
Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another. The former is trivial; reduce the task pool size to a single thread. The latter is definitely harder, but modern tooling (I'm partial to VS2017's Threads window) makes this a much more achievable thing; you can break across all of them and step between them effectively.
> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
I find myself debugging in environments where I can control timeouts, but if you can't, yeah, this is totally a problem. Leaving a service paused for ~3-5 minutes while I poke at it doesn't drop connections with my dev configs, though.
> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
"Doctor, it hurts when I do this..."
If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice--you have a monolith that communicates over pipes rather than function calls, and that's strictly worse in the first place.
>> It's often hard to run a stepping debugger when you have an embedded hardware at hand.
> Totally true. But that's a pretty rare situation.
I know it's rare to work with embedded systems if you don't work with
embedded systems. Though when you do work with them, this "rare situation"
suddenly becomes prevalent.
>> It's equally hard to run such a debugger when you have multi-threaded code.
> Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another.
It all works well until it doesn't. That is, until you need two threads to
communicate with each other (otherwise, why are they even running in the same
process?).
>> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
> I find myself debugging in environments where I can control timeouts, [...]
All of them? My simplest cases have dozen timeouts one behind the other, at
different levels of the stack. Even though I potentially can set them all,
it's all very tedious. Not to mention that the timeouts can interact in
non-trivial ways, so it's often hard to track all of them.
>> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
> If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice
Also, I haven't said that "you can't effectively stub out an environment".
There are other difficulties around debugging microservices, like mentioned
before controlling timeouts everywhere.
With frontend JS, I usually find the friction of using a debugger lower than the friction of adding logging since I don't have to reload to add/remove it. You can even add a conditional breakpoint that logs and always returns false to capture the effect of adding a log statement.
I rarely use the step functionality, though, because it just takes too long. More frequently when I hit a breakpoint, I examine the current state, figure out the next place that I am interested in stopping and then add a breakpoint there before resuming.
Debuggers are complicated and create dependency. How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours.
I'll break out a debugger if all else fails, but it's not my first choice.