How do you encourage someone to learn to use the debugger?

Question

We are in college and I want get my projectmate to use the debugger as it will help improve his debugging speed. Despite offering to show him how to use it so that he won't have to learn it by himself, he refuses and to date still uses printlining to debug.

I can understand why he refuses as he's probably afraid of the learning curve (Even though it's actually trivial. Besides computing students cannot be afraid to learn new things). I myself had resisted learning how to use a debugger for as long as I could for the very same reason. The moment I tried to use a debugger for a person project I found how useful it was to a programmer's productivity and have never looked back since.

So how would you go about making someone virtually impervious to you to learn something for his own benefit? Or should I not try too hard to help people like him?

Edit: Just an update for myself. Basically our project is drawing to an end and there are lots of bugs here and there. So he told me that foo("x") doesn't return anything but when I tried it does return what it's expected to return. In the end I make a breakpoint at the offending code and found that the argument in foo(string aString) was actually ""x"" instead of "x". Granted it's an oversight by the person passing him the string, but with the debugger I managed to find out the problem quickly (trying to confirm the assumptions he said) without having to go through all the code. =)

Answer 1

I would give a quick demo of how quick and easy it is to set up and to do. A recursive example might be best because printlining usually falls over here with masses of output, but with a decent debugger you can put conditional statements in.

Answer 2

When he's stuck trying to debug something and can't figure it out, offer to take over using the debugger. When he sees how well it works for a real problem, he'll come around.

Answer 3

a CS student that strongly resists learning new tools is headed for a stagnant career; don't waste too much time on him

if you're really concerned, email him a link to this thread ;-)

Answer 4

I say let natural selection take it's course. If someone refuses to make life easier on themselves, maybe programming isn't for them.

Update: I would appreciate some comments as to the number of down votes as well, since an answer posted seconds before mine with similar advice is receiving positive votes. We have here a person saying that a friend who is taking similar classes refuses to use a debugger other than print lines, etc. Perhaps he protests such learning on principle. I doubt that, since they are only learning fundamentals now. Also, that is not presented in the question. He is refusing to learn something that might make things a little easier.

From my experience in school, there are a number of computer science students who are just not cut out for it. If he is resistant to even putting this tool into his tool kit, then this might be a "bad smell" for his resistance in learning anything beyond what he is required to use everyday.

I don't think that debuggers are the only way, or even the best way. However, I know how to use them, because one day it may help. Maybe my terse answer sounded too harsh.

Answer 5

Presumably, he is not experiencing a hard-enough problem as yet that he can live without a debugger. Or he just wants to feel miserable!

Answer 6

Challenge him to solve the same problem, or series of problems. If you're able to solve them faster using a debugger, he'll have his answer. If not, then leave him alone.

Answer 7

Forget about forcing him to learn. People don't learn very well when forced, and he seems quite set in his ways despite what seems to be various generous offers to help him. As long as he's actually being productive and not holding your project back I'd say let him stick to his ways.

Of course, if his printline debugging starts becoming an issue you might want to bring it up again.

While printline debugging can be useful, it's one of many tools in a programmer's arsenal. And while many people seem to be upset about the implicit criticism on printline debugging, the central criticism is towards refusing to expand one's toolset. Any programmer who doesn't know how to use a debugger is found just as lacking as any programmer incapable of using a logger to pinpoint a problem.

Because seriously, the moment I read this question's title, the first thing I thought to myself was:

What programmer wouldn't want to see the state of the program while it's running, like a good debugger can?"

Answer 8

To be fair, heavy reliance on a debugger to understand code is a "code smell" that indicates that the code is not as well-written or structured as it could be. That doesn't seem to fit what you're describing, but it's worth taking a step back and asking yourself "Why is it that I can't understand and reproduce the state of this function / method without a debugger? Should I lift the control flow to a higher level? Should I modularize the blocks into separate functions? Do I rely on variables whose assignments are lost in the mists of time and, if so, can I reduce, rename, and encapsulate them?"

Debuggers are great tools, but they can be used to "get away with" leaving code in a poor structure, which is in opposition to the modern emphasis on refactoring code into a better form.

Answer 9

Your question was "how" to influence him to learn to use the debugger. You could try racing him to find the answer to a "bug" - see who figures out a problem first.

If he's truly impervious to your suggestions, let him be - some people will never listen to some, while they may listen to others. Stinks, but its human nature.

Answer 10

There are certain classes of problems where not using a debugger is quicker. This is especially true if you have good logging. Often, when searching for a bug, I'll go in and add additional logging to capture the problem (which is basically like using printf, but it's a permanent change instead of something to be deleted later). That way, next time a similar problem crops up, the logging is there already. Of course, there are also a whole bunch of problems where the step-through debugger is way easier :) Everyone should know how to do both.

Answer 11

You're begging the question by assuming that a debugger is superior. In my personal experience, dependency on a debugger leads to not understanding what the underlying problems actually are and patching until the symptoms go away. I think, in general, that you're better off standing back and thinking about whether the code actually expresses your intent, and using debuggers as a last resort when you can't figure out what's happening.

As evidence, I present coworkers who've spent 90% of their time stepping through breakpoints and waiting for the answer to jump out at them, or writing messy code knowing that they can catch problems later if necessary.

I don't think there's anything inherently bad about debuggers and that they're really very useful, but that programmers all too often become reliant on them.

Answer 12

Ask him to help you debug something or understand what's going on. Then while he is with you start using the debugger. Other than that, there's not much you can do to force the issue.

Answer 13

To me the answer is plainly obvious: Don't try to force others to do things your way. All it does is frustrate you and angers them.

Answer 14

To motivate others, it helps to understand what they like, how they think, and what makes them tick. If you really want him to learn to use a debugger, try to make it interesting to him. Debate what machine code instructions a compiler will generate. Challenge him to write his own debugger or figure out how they work internally. Tell him you can't figure out how to break when a variable changes. If you can make it into something he wants to do, you'll have much better luck.

Answer 15

So far I've seen a lot of back and forth on whether debuggers make you a better programmer or whether a "real" programmer needs a debugger to understand the code.

I don't think that's important really. There are right and wrong ways to use every tool.

With the debugger, sure you could just set a bunch of break points and step through your code waiting for an Exception to get thrown or something similar. But the point is that you should be using your debugger in exactly the same way as you would statements that would print out some useful state information about your program. It just allows you to do this without having to insert extra lines of code and/or conditional prints.

Answer 16

Personally, I almost never used the debugger until I actually started working on production code, and attempts to convince me of it's benefits over printline were largely unsuccessful. I don't think the debugger is really that much better than printline debugging on small projects. Considering some of my applications consistently trigger BSODs when trying to debug them via the debugger, I still often find myself unable to use it. Printline debugging is rarely insufficient when done right. The true beauty of the debugger comes when you tell it to do things like, "break when state of err_flag changes." or "break on any exception."

I've found that the debugger often works very well with printline debugging, the latter often being asymptotically faster at finding bugs in exchange for absurdly high constants. They work together much the way some sorting algorithms use other sorting algorithms for very small sets.

Answer 17

o_0

Are you guys insane? It's 2008 and the debugger is an essential tool if you want to understand a large application and locate tricky problems. Being able to:

• Find out if a call to a method is within object a, or object b by inspecting object state in breakpoints.
• Investigate the state of the application in a certain scenario (query certain objects etc).
• View the stack-trace
• View the threads running in the application

Is an essential tool that is only repeatable via a lot of legwork with print lines. I mean sure I could use print lines to find this stuff and dribble printfs all over the code base but whats the point when technology exists to make this irrelevant?

On the odd occasion I do use print statements (particularly with timing issues) and there are certain yet limited scenarios where the debugger can interfere with debugging but stating that it's a better tool or "dependency on a debugger leads to not understand what the underlying problems actually are" is an utter nonsense.

The debugger is a tool to help you understand application state in real time, in the vast majority of cases there is little advantage to be gained over re-inventing the wheel with your own test code.

Gaining experience with a debugger will teach you how to understand the sort of problems you are creating because you will have a greater power to understand the current state of the application leading to a epiphany that begins with "......wtf?".

As per the original question, hit him/her over the head with a plank of wood, there's no excuse to taking such a luddite approach to modern tools. Better still, give them a book on ASM and a BBC micro to use if that's their approach to modern technology.

Answer 18

In VS 2008 the debugger is so easy to use that unless you don't have an hour to spare for this project, there's no good reason that your partner shouldn't at least try it. It could be much faster than printing out extra lines and the internal state.

That said, there are times when printing out extra lines is much faster, but in most classwork sized programs that isn't normally the case, since most classwork starts at pretty much exactly where the problem is likely to occur.

Answer 19

Honestly, I hate using the debugger but view it as a necessary evil. Note: this only applies to using modern languages with tooling support to allow easy TDD. I rarely use the debugger, and when I do I really feel like I've failed to write well-factored code. There are certain cases that are very hard to unit-test (ASP.Net WebForms for example) where the debugger is the only real option, but outside of that, for me, using the debugger means that I need to clean up that section of code and make it more understandable. Of course, sometimes you inherit code that needs to be stepped through in the debugger just to try to gain an understanding.

Answer 20

If you can program a specific printf that tells you exactly what you need to know, and then run and see the results in a few seconds, then this is better than any debugger. If the build cycle takes a minute or two, we are getting into a gray area. If the build cycle takes many minutes, then use a debugger.