Hacker News Reader

I think this is a problem of language and communication (what he says in the post vs what we receive and understand reading it). I feel like I've groked what he's saying because I have a similar mindset.

Yes, debuggers are useful in some circumstances, but most of the time I don't reach for one. I usually start out by looking at the code surrounding a problem and thinking about what circumstances could lead to the erroneous data. From there, it's pretty simple to stuff in some carefully selected print statements to make it report on some of the things it's doing, so that I can check my assumptions. More often than not, this is enough to identify the underlying problem in a few minutes and fix it. Either that, or I get some pointers to other areas that should be investigated.

It's only when this initial triage fails to give me any meaningful leads that I start thinking about what tool will likely be the most effective for the problem at hand. It's usually a judgment call based on how complicated it will be to separate relevant data from irrelevant, and what tool will most efficiently give a window complete enough to describe what I'm looking at, yet small enough for my brain to hold it all. Also, the need for aggregate vs individual data will play a role in the decision. Sometimes this phase is likely to be faster with a debugger, sometimes (and in my 20 years experience, usually) not.

> I consider vision to be a drug -- an addiction. People can get into the horrible habbit of depending on their vision instead of on their brain. IMHO looking at things is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just trying to do the action again, then you may need to open your eyes.

Coding without a debugger is like walking with your eyes closed or driving at night with no headlights. Sure, it may be possible, but you are purposefully limiting your information in order to not become "dependant" on something.

Tooling will always be a compromise of utility vs reliance but there is a reason we don't, for example, build cars by hand any more.

Exactly, we're engineers and craftsmans, all which rely on their tools. If you don't use the tools at your disposal, you're not a good professional.

If you don’t use your brain first you’re not a good professional. Any other tool isn’t as important.

My experience is the EDI and debugger depedent programmers have a very hard time when those things are taken away or unavailable. The reverse is not true.

As I stated a few days ago [1], there are times when you have no debugger (or a debugger won't help you as was in my case). Learning to debug via print() is a useful skill to know.

[1] https://news.ycombinator.com/item?id=19723753

Ironically, I think you've left out some nuance to the author's position:

> ... and I almost never use a debugger.

Even if he can't recall the last time he used it, he keeps the tool in his toolbox.

His article was quite inflammatory however and it's easy to see how someone who relies on a debugger would feel attacked and insulted.

I look around my team and I see some turning to debuggers first and others to outputting at key points. I see zero correlation to effectiveness or efficiency.

Debugger is like IDE. Most people use it and leverage their power, increasing their productivity. Some people insist on using primitive editors.

Depending on the problem / project both of them could be right.

I also use intellij for big projects but I prefer emacs/vim for little scripting stuff or tiny programs.

IDEs help navigate and refactor big stuff while editors have less overhead and force you to use your brain a bit more.