Several times, sometimes to find out when an incompatibility was introduced in an upstream dependency to find the maximum compatible version, but usually to find the commit that introduced a strange bug.
The process is always the same… Write a unit test, start bisect, check test select next bisect step, repeat. If your last-known-good and first-known-bad are correct, it always worked for me.
I’ve seen the fun of “prints everywhere” in production when a colleague forgot to remove a “Why the fuck do you end up here?” followed by a bunch of variables before committing a hot-fix… Customers weren’t to amused…
Edit: That was a PHP driven web shop and the message ended up on to of the checkout page
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…
Elon Musk supports eliminating rights for people who aren’t Elon Musk… That’s about it, I think…