deleted by creator

As a C# programmer I use the debugger every single day, since it’s so natural and easy to use as to just run the application. I’ve grow spoiled actually, when I program in Go or Rust I really miss the “it just works” debugger.

I use debuggers all day every day. If I’m running something in development, there’s a very good chance I have it connected to a debugger. Also use it whenever I encounter an unexpected behavior in production (we use our own product for work too)

The profiler is a lot more specific and I haven’t used it in a while.

I have a tendency to just use console logging, and only use debuggers when things are starting to get hairy.

I seldom use profilers because I seldom need to. It’s only usefull to run a profiler if your programm has a well defined perfomance issue (like “The request should have an average responsetime of X ms but has one of Y ms” or "90% of the requests should have a response after X ms but only Y% actually do).

On the other hand I use a debugger all the time. I rarely start any programm I work on without a debugger attached. Even if I’m just running a smoke test, if this fails I want to be able to dig right into the issue without having to restart the programm in debug mode. The only situation, where i routinely run code without a debugger is the red-green-refactor cycle with running unit tests because I’ll need to re run these multiple times with a debugger anyway if there are unexpected reds…

What enables me? Well there’s this prominent bug-shaped icon in my IDE right besides the “play button”, and there’s Dev-Tools in Chrome that comes with the debugger for JS…

Running your code without a debugger is only usefull if you want to actually use it or if you’re so sure that there aren’t any issues that you might as well skip running the code altogether…

I’ve used a debuggers only a handful of times in the last decade or so. The projects I work on have complex stacks, are distributed, etc. The effort to get that to run in a debugger is simply not worth it, logging and testing will do 99.9% of the time. Profiling on the other hand, now that’s useful, especially on prod or under prod load.

I recently started doing xeyes debugging.

We have so many debug logs that trying to find your log of a background takes a non zero amount of time.

So just inserting system("xeyes"); is actually way easier, to get instant feedback, and you can just use system("xmessage msg"), if you need a message.

I find debuggers are used a lot more on confusing legacy code.

Lately, monitoring tools such as OpenTelemetry have replaced a lot of my use of profilers.

Really often, even since TurboDebuger in the 90s, no other way to trace your code, step over/into, watch variables, etc. For compiled program it’s necessary. For javascript I use print lol

At my last job, doing firmware for datacenter devices, almost never. JTAG debugging can be useful if you can figure out how to reproduce the problem on the bench, but (a) it’s really only useful if the relevant question is “what is the state of the system” and (b) it often isn’t possible outside of the lab. My experience with firmware is that most bugs end up being solved by poring over the code or datasheets/errata and having a good long think (which is exactly as effective as it sounds – one of the reasons I left that job). The cases I’ve encountered where a debugger would be genuinely useful are almost always more practically served by printf debugging.

Profilers aren’t really a thing when you have kilobytes of RAM. It can be done but you’re building all the infrastructure by hand (the same is true of debugger support for things like threads). Just like printf debugging, it’s generally more practical to instrument the interesting bits manually.

Pycharm debugger has been great for me recently, I love the feature where you can drop into an ipython repl and interact with your program state.

This usually depends on which industry you work in, and what language you’re using usually :)

I work in gamedev, c++, and I ALWAYS use a debugger. There’s no running the game, or even the editor without the debugger connected. No matter if you need it currently or not. You always launch the project through the debugger so if anything comes up you can investigate immediately.

Profiler is used any time there’s a performance problem.

I used to just use print statements and avoided debuggers because I didn’t understand it. But as I’ve gotten more experienced, it’s become my first choice in debugging now (go figure haha).

All the time. I deal with a lot C# code that makes and responds to HTTP API requests, and being able to check if requests and responses are properly formed without having to slap print statements everywhere is a godsend.

One of the thing I learn about in programming is that, if you have to use debuggers too often then maybe it’s a good time to re-evaluate on how you develop a project.

1. Did you misunderstand the pattern design?
2. Were there something you don’t understand?
3. Maybe it’s an indication that you need to document more and do some project designs before committing the implementation?
4. Were the way you write code more prone to bugs?
5. Are there any libraries or tools that can help you alleviate this?

By fixing your practice and making it less prone to bugs, you wouldn’t have to resort to using debugger as often.

As for profilers, it really depends, but generally if you try to be conservative like applying lockless concurrency where possible and sometime resorting to mutex/semaphore if otherwise needed, you should generally be ok when dealing with concurrency situation. As for overall performance, the rule of thumb is that, the less code you run to do the work, the better. You can see what program would actually do when dealing with C language for instance, but you might have a harder time to make such evaluation on higher level languages, so the general wisdom is that the heavy computation operation should be deferred to low level language like C language and you should have high level language calls into that C function to handle those performance intensive operations.