> Leave us be. We know what we’re doing.

No shade, this was my perspective until recently as well, but I disagree now.

The tipping point for me was the realisation that if I'm printing code out for debugging, I must be executing that code, and if I'm executing that code anyway, it's faster for me to click a debug point in an IDE than it is to type out a print statement.

Not only that, but the thing that I forgot to include in my log line doesn't require adding it in and re-spinning, I can just look it up when the debug point is hit.

I don't know why it took me so long to change the habit but one day it miraculously happened overnight.

▲

MangoToupe 5 days ago | parent [-]

> it's faster for me to click a debug point in an IDE than it is to type out a print statement

Interesting. I always viewed the interface to a debugger as its greatest flaw—who wants to grapple with an interface reimplementing the internals of a language half as well when you can simply type, save, commit, and reproduce?

	▲	DavidPiper 4 days ago \| parent \| next [-]
		Depends on your language, runtime, dev tooling. I'm using IntelliJ for a Java project that takes a very long time to rebuild, re-spin and re-test. For E2E tests a 10-minute turn-around time would be blazingly fast. But because of the tooling, once I've re-spun I can connect a debugger to the JVM and click a line in IntelliJ to set a breakpoint. Combined, that takes 5 seconds. If I need to make small changes at that point I can usually rebuild it out exactly in the debugger to see how it executes, all while paused at that spot.
	▲	jennyholzer 5 days ago \| parent \| prev [-]
		> who wants to grapple with an interface reimplementing the internals of a language half as well when you can simply type, save, commit, and reproduce? i do, because it's much faster than typing, saving, and rebuilding, etc.