Is using a debugger lazy?

Yes, using a debugger is lazy. But lazy is good. I'm lazy.
Though it might make you think lazily, and that's not good.

Do you think using a debugger is lazy?

No, using debuggers are absolutely legal. It is just a tool like a screwdriver.

I wouldn't listen to him - your instincts are right, he's out of his mind. A debugger is not only a great tool, it's absolutely indispensable if you want to get anything done.

That's just plain arrogance there. Either that, or stupidity.

The whole point of an IDE that has great debugging capabilities is to make a programmer more productive. Its a tool in your toolbox (as the previous poster beat me to that analogy). Does this professor consider re-using code as being lazy?

Most commercial software is pretty big - hundreds of thousands of lines of code if not millions, usually with many complex layers. Tools like debuggers help to shift through all the noise and pin point whats breaking and blowing up. That's not "lazy", that's being "smart".

Tools like debuggers help to shift through all the noise and pin point whats breaking and blowing up. That's not "lazy", that's being "smart".

When I said something along these lines to him, his reply was "What you call smart, I call lazy."

To be completely fair, I told him that using a debugger helped me with a lot of null references when I was trying to handle data from files that somehow never loaded up during runtime (something I've always thought was a fairly common, small mistake people make), and his response was that those situations rarely arise for him. To me that seems like a questionable claim, but again, I'm just a beginner. Furthermore, he said that he just uses error messages to let him know whenever something goes wrong. But isn't that in itself a flawed idea to begin with? Since you only put error messages where you expect errors to occur, when a problem pops up in an unexpected place your error messages won't mean anything.

In these situations I struggle to know when to be adamant about my point or open about the fact that I could be totally wrong.

He's either the type of professor who hasn't written any significant code in the last 10 years, he's out of his mind, or he was pulling your leg.


If he's recently practiced, sane, and not joking, then run--don't walk--to the nearest exit, and get the hell out of dodge.


I'm only half joking.

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.[/quote]
? Bill Gates

More seriously, he's right that you should not rely on the debugger to check your program unless it's really so complicated that you can't keep it in your head.

Before you start laying down code, you should already have a mental model of how it works -- you never just start throwing down code you think works, and then pop into the debugger to tweak it piecemeal until it works. In short, you should strive to understand the code before you ever write it down. It sounds like you're a beginner, so this skill will develop and grow over time.

In the mean time, the debugger can be an invaluable tool in your own exploration of how code works (when you read others' code) and it's always a good tool for fixing errors that you just can't seem to reason out -- That's why they were created in the first place. People mess up, no one's infallible, not even Professor Bighead.

Here's another quote -

"Those who do, do. Those who can't, teach".

Not to throw a shoe at all academics, as some do great research. But there are those bad apples that just leave a bad taste in your mouth when you leave school.

[quote name='Starnick' timestamp='1347991811' post='4981323']
Tools like debuggers help to shift through all the noise and pin point whats breaking and blowing up. That's not "lazy", that's being "smart".

When I said something along these lines to him, his reply was "What you call smart, I call lazy."

To be completely fair, I told him that using a debugger helped me with a lot of null references when I was trying to handle data from files that somehow never loaded up during runtime (something I've always thought was a fairly common, small mistake people make), and his response was that those situations rarely arise for him. To me that seems like a questionable claim, but again, I'm just a beginner. Furthermore, he said that he just uses error messages to let him know whenever something goes wrong. But isn't that in itself a flawed idea to begin with? Since you only put error messages where you expect errors to occur, when a problem pops up in an unexpected place your error messages won't mean anything.

In these situations I struggle to know when to be adamant about my point or open about the fact that I could be totally wrong.
[/quote]

Maybe he thought the problem was overblown, e.g. you should be checking if the data is there or not when you initially load up that resource. Either throw an exception or log an error. That then can get tricky, because do you simply cease execution or do you have a "MISSING" default resource that gets used. In my opinion, just blowing up or simply not showing anything (depends on the type of resource...I'm thinking in terms of some graphic resource here) is a bad idea as it doesn't help the developer pin point whats missing or at what point it was found to be missing without requiring the person to dig into the code.

Error messages (codes) vs throwing and catching exceptions is pretty hot debate among most people. At least in my office, its a nearly a religious argument between some people.

Before you start laying down code, you should already have a mental model of how it works -- you never just start throwing down code you think works, and then pop into the debugger to tweak it piecemeal until it works. In short, you should strive to understand the code before you ever write it down. It sounds like you're a beginner, so this skill will develop and grow over time.

Thanks for the advice. I try to stay cognizant of this as I use it. I lay out my code in a notebook and try to plot as much of it as possible before I even look at the computer. Even then, later on you always get an idea and decide to restructure some underlying base code. Sometimes you don't quite get rid of all the old code and later on issues arise. This is where the debugger has really saved me a ton of hours. I think a good philosophy is not to lean on the debugger, but try to stand on your own and have it there to catch you every once in a while when you fall.

I agree to what has been said above, you should understand what you want to do, how you want to do it, before actually trying to do it. Now, anyway, I suppose that person has never done any real life work now, has he? Deep inside millions of lines of code, debugging by writing to the console, or just by knowing where the problem is. Things are really not that simple.

One of the professors told me that he preferred Dev-C++, which I found quite odd considering Dev-C++ at least seems very bare-bones (I wouldn't know, I've only written a couple very simple projects in it).

I doubt he/she ever programmed much in the last five-ten years. Dev-C++ is completely bugged, not compatible with Windows Vista and 7 and not updated since 2005. It is probably one of worst free IDEs out there. Saying it is better than Visual Studio 2010 is just ignorance or stupidity.

Now something tells me he's out of his mind

He is out of his mind.

He may have a point that in your particular example you are using the debugger to catch things which are just the result of "lazy" coding. For example, you should not generally assume that a file will be readable and in the location you expect, and your application should make you aware of missing resources before any weird behaviour or crashes in other parts of the code creep in. Issues with the availability of files or other resources (like remote servers) are extremely common, and sooner or later you will learn the lesson that it is a good idea to handle these cases explicitly in your code.

He may also have a point that some people have a bad habit of coding without thinking and then routinely have to use the debugger to find basic errors - this is clearly not a great way to work.

But to make the general statement that debuggers should not be used is, in my opinion, very closed-minded and verging on bat-shit insane. Arbitrarily deciding to never use a tool just does not make sense. I still do "printf debugging" sometimes, as it is necessary in some environments and sometimes quicker for simpler debugging tasks where you already have a decent idea of what is going on. However, there are times when stepping through code is pretty much the only reasonable way to track down the source of a bug. This is especially true when using third-party code or working on a large team project.

I found debuggers to be far more useful in my earlier stages than I do now. Once I nailed down my personal libraries and usage patterns, I had far fewer bugs of the sort that a debugger can quickly help with. I can kind of understand where the professor is coming from, in a weird sort of way, though. It is kind of lazy to use a debugger, rather than study the code and reason out the flaw yourself. But lazy translates to time-saving in this case, and if you're writing code on a schedule (something an academic rarely has to do, in my experience) you can't really afford the luxury of skipping the debugger.

The fact he uses Dev-C++, though, is frightening.

A debugger can also find faults that you can't use reasoning to find. For example, a module that you only have the binary for is loaded into the same address space as your program. It writes a random byte somewhere in your memory, and we're lucky; they didn't strip debugging symbols. We can now use a debugger to get a beautiful call stack, pointing into their software.

A debugger is the code equivalent of a multimeter/oscilloscope/magnifying glass etc for electronic circuits.
What your professor is suggesting is to find the cause of failure in a complex circuit by just looking at the wires or maybe by putting a lightbulb here and there.

Clearly, he is out of his mind.

Either that or there was just a misunderstanding.

Is using a debugger lazy?[/quote]
From a theoretical standpoint (where your professor is likely coming from), yes, using a debugger is lazy. It indicates that you didn't design a robust architecture, or code defensively in order to prevent bugs from occurring in the first place.

If you are programming in a low-level language (C, C++, assembly, etc.) then using a debugger is an unfortunate necessity. The language just doesn't protect you from enough sources of error (address space issues, bad pointers, type erasure, etc.) to successfully code in a defensive manner.

That said, for higher-level languages I find debuggers to be at best a useful, if generally superfluous, tool. I don't think I use a debugger in a high-level language (Java, Scheme, Erlang) more than one or twice a month.

That said, for higher-level languages I find debuggers to be at best a useful, if generally superfluous, tool.

I think we can agree that javascript counts as a high level language. If so, I am using a debugger on an almost daily basis to find out why the code I have wri.... the code my colleagues have written doesn't work anymore.

Sounds like VS debugging is too much of a newfangled tool for him and back in his day they had to code for 15hrs to do a helloworld program. And in machine code too!

The debugger is a tool to make it easier to find problems in code, but, hey.. we are human and we love making tools to be "lazy". A calculator is for lazy people who don't want to do math, cars are for lazy people how don't want to walk, writing things down is for lazy people who don't want to commit things to memory. But new tools helps improve the quantity and/or quality of our work.

But to his defense with new tools we do become lazy in the since we now tend to cut corners since the speed of produce has increased. Why plan ahead when you can use start something and debug until I get it right? If you only Dev-C++ you find planning ahead and remembering how to use functions correctly else you'll be spending all day fixing bugs.