4 ms·
> 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 realis
by DavidPiper 1y ago
> 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 1y ago> 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?
- jennyholzer 1y ago> 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.
- DavidPiper 1y agoDepends 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.