Today I was talking with a few professors at my university about doing some work on a couple new servers they've got set up. They asked me about my background in coding, and I mentioned that I'd written a couple games over the summer with C++/Allegro, and that I used Visual Studio 2010 as my IDE. 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).
Anyway, I told him I thought he'd find VS2010 to be nice because the debugger is great for catching unhandled exceptions/null pointers, and he told me that debuggers are for lazy people. Now something tells me he's out of his mind, but I'm no expert, so I can't be sure. Do you think using a debugger is lazy? I don't mean overusing it, or relying on it too much. Just the simple act of using it at all. I think a debugger is a great tool and it's a good idea to use one. What do you think?
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.
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".
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".
Author
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.
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.
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.
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.
"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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
