4 ms·
I'm at my least productive when I can't use a debugger (Jenkins jobs, nginx config, networking stuff). Everywhere else, getting it set up is my top priority. *
by Noumenon72 4y ago
I'm at my least productive when I can't use a debugger (Jenkins jobs, nginx config, networking stuff). Everywhere else, getting it set up is my top priority.
* I usually fix the bug right there in the debugger where I find it. It's so much easier to fix logic in a REPL with all the actual variables available then in a slow guess-and-rebuild cycle.
* Being able to inspect complex objects is so much more convenient when you can right-arrow your way through the levels or watch a nested subpath.
* I'm constantly surprised and confused as I make my way through code. Reality contradicts my assumptions at every step so I need the ability to see that to find my way to the bug at all.
* I love log statements, but I typically need the debugger to find the place to add the log statement. There are so many candidates I'd have to add five prints for every one I use.
- hamburglar 4y ago> I'm constantly surprised and confused as I make my way through code. Reality contradicts my assumptions at every step so I need the ability to see that to find my way to the bug at all. This is a huge point that a lot of people miss. When I was a junior dev working on some shrink wrap software, I’d submit a change for code review, and my stickler boss would read it and then say “have you single stepped through the main path of this code yet?” I found this annoying, but he made me do it, and god damn it if I didn’t often encounter situations where the code apparently worked, but I caught subtle errors by watching the state change one step st a time. “Oh my god, this value is never even looked at and I’m getting lucky it never fills the buffer on subsequent iterations!” It’s very, very eye opening. It became clear that it’s hubris to read a piece of code and assume I can interpret it faithfully. The debugger gives you another picture of reality.