3 ms·

I am sometimes (i.e. I think this happens a lot) bit puzzled by looking at very intelligent people who doesn't know about the debugger or knows about it and doe

I am sometimes (i.e. I think this happens a lot) bit puzzled by looking at very intelligent people who doesn't know about the debugger or knows about it and doesn't use it anyway. If you program Java then please feel free to use the excellent tooling that is available.

jjoonathan 10y ago
It's just habit. Code in a language with bad tooling and you too would develop habits to work around the lack of tools. It just takes time (and sometimes a bit of convincing) to adjust. And to adjust back, of course. "Type A" coders are especially vulnerable to this kind of habituation on account of often being interested in esoteric languages, systems programming, or other "extreme" environments with tooling restrictions.
- TeMPOraL 10y ago
  It helps also to not make the type of bugs that need to be solved with the heavy and laggy Java debugger. I've been doing quite a lot of Java over the years, especially in the last year, working on medium and large projects. I've compared my workflow to that of my cow-orkers, and I sometimes look at the way they debug things. For most cases, I can find and fix the bug with occasional logging / print statements faster than my cow-orker can pause the program on breakpoint and then click through stuff to find the right element in the right container in the right variable that's maybe causing the problem. The trick usually is to test often and don't write something if you don't understand how it works - that also includes interacting with parts of your application that you didn't write - and to not proceed if you feel you don't understand how the code you wrote works. 99% of the time when I have a bug in my Java code I realize where the bug is before my window manager switches over from the program to the IDE. That comes simply from understanding what one wrote (+ a bit of experience). That said, debugging multithreaded programs is a pain in the arse, and I take any help I can get there. Though I haven't seen many debuggers that would be helpful in those cases. Interactive debugging is fun in Lisp, where you basically code interactively all the time and code/debug phases are pretty much blended together (just like compile/load/runtime is).

jjoonathan 10y ago

It's just habit. Code in a language with bad tooling and you too would develop habits to work around the lack of tools. It just takes time (and sometimes a bit of convincing) to adjust. And to adjust back, of course. "Type A" coders are especially vulnerable to this kind of habituation on account of often being interested in esoteric languages, systems programming, or other "extreme" environments with tooling restrictions.

TeMPOraL 10y ago
It helps also to not make the type of bugs that need to be solved with the heavy and laggy Java debugger. I've been doing quite a lot of Java over the years, especially in the last year, working on medium and large projects. I've compared my workflow to that of my cow-orkers, and I sometimes look at the way they debug things. For most cases, I can find and fix the bug with occasional logging / print statements faster than my cow-orker can pause the program on breakpoint and then click through stuff to find the right element in the right container in the right variable that's maybe causing the problem. The trick usually is to test often and don't write something if you don't understand how it works - that also includes interacting with parts of your application that you didn't write - and to not proceed if you feel you don't understand how the code you wrote works. 99% of the time when I have a bug in my Java code I realize where the bug is before my window manager switches over from the program to the IDE. That comes simply from understanding what one wrote (+ a bit of experience). That said, debugging multithreaded programs is a pain in the arse, and I take any help I can get there. Though I haven't seen many debuggers that would be helpful in those cases. Interactive debugging is fun in Lisp, where you basically code interactively all the time and code/debug phases are pretty much blended together (just like compile/load/runtime is).