Why aren't students taught to use a debugger?

I don't think the problem is teaching. Using a modern graphical debugger is not rocket science (at least not for most user-mode programs running on a single computer). The problem is with the attitudes of some people. In order to use a debugger effectively, you should:

• Admit it's your fault and select isn't broken.
• Have the perseverance to spend a couple nights debugging, without forgetting the previous point.
• There's no specific algorithm to follow. You should guess educatedly and reason effectively from what you see.

Not many non-programmers have these attitudes. At college, I have seen many friends who give up after a relatively short period of time and bring me some code and tell me the computer is doing something wrong. I usually tell them I trust their computer more than them (and this hurts some feelings, but that's the way it is).

In my high school and university, most of the people in the classes didn't really care about programming at all.

If by students you mean Computer Science students, I think the answer is fairly obvious. The subject matter for courses is generally theory, with the programming language / framework / library there as an aid. The professor can't go very far in depth on a particular tool, since it would take away from time he is teaching networking or systems or whatever. Maybe if there were a course called "Real World Programming" or something like that, they'd cover debuggers, but in general I don't see too much wrong with expecting students to read the language / tool documentation in order to accomplish the coursework.

Debuggers were introduced in my second year Intro to C course, if I recall correctly. Of course the problem most students were struggling with at that point was getting their work to compile, which a debugger will not help with. And once their ten line command line program compiles and then crashes, well, they already have some printfs right there. Fighting to master GDB is overkill.

In my experience, it's fairly rare to actually deal with a code base large enough to make more than a cursory familiarization with a debugger worth the time investment in most Comp. Sci curriculums. The programs are small and the problems you face are more along the lines of figuring out the time-space complexity of your algorithm.

Debuggers become much more valuable on real world projects, where you have a lot of code written by different people at different times to trace through to figure out what keeps frotzing foo before the call to bar().

This is a good question to ask to the faculty at your school.

At my university, they gave a very brief example of debugging, then pointed us to the "help" files and the books.

Perhaps they don't teach it because there is sooo much stuff to cover and so little time for the lecturers. The professors aren't going to hold everybody's hand.

Not entirely related, but people need to use debuggers not just for debugging but to understand working code.

I'll put in a cautionary note on the other side. I learned to program with Visual Basic and Visual C ( mid 80s ), and the debuggers were built-in and easy to use. Too easy, in fact... I generally didn't think about how to solve a problem, I just ran it in the debugger and adjusted the behavior. Oh, that variable is one too high... I must have to subtract one here!

It wasn't until I switched to Linux, with the not-quite-as-easy gcc/gdb combo, that I began to appreciate design and thinking about your code first.

I'll admit, I probably go too far the other way now. I use a debugger to analyze stack traces and that's about it. There should be a middle ground between analyzing the problem and stepping through it in a debugger. Certainly people should be shown all the tools available too them.

I was taught to use a debugger in college. Not much, late (it should be almost the second thing to teach), but they taught me.

Anyway, it's important to teach to DEBUG, not only to "use a debugger". There are situations where you can't debug with gdb (e.g. try to debug a program running 10 concurrent threads) and you need a different approach, like the old-fashioned printf. I can certainly agree with you that usually one learn and make use of debug techniques much later that the first time you could use them.

From a practicality standpoint, most likely (due to policy or technical restrictions) you cannot use a debugger on a production application. Not using the debugger as too much of a crutch promotes adding the proper amount of logging to your application.

Because there is not text book on debugging, period.

In fact, it is very hard to create a teaching situation where get the incentive to use a debuigger. Typical assignments are too simple to really require a debugger. Greg Wilson raised that topic at last year's SUITE workshop, and consensus was it is very hard to get students to use a debugger. You can tell them about debugging, but creating situation where they will actually feel the pain of resorting to the debugger is hard.

Maybe a lecture on game cracking could motive students to step through the game with a debugger? At least, that was why I told myself how to use a debugger as a 12-year old :)

A found that there is a lot of negative attitude towards debuggers amongst academia and seasoned systems programmers. I have come up against one quite talented programmer who claimed that "Debuggers don't work, i just use log files." Fair enough, for multi-threaded server apps you must have logging, but there's no denying a debugger is useful for 99% of the code that is not multi-threaded.

In answering your question, yes debuggers should be covered in programming syllabus, but as one of the tools of debugging a program. Tracing and logging are important as well.

Having recruited at 4 universities (Rensselaer, Purdue, Ohio State, University of Washington) - students that write code for money for incubators associated with their university tend to learn the art of debugging really well because the incubation companies want people to solve problems and do it in fewer hours and invest some time to teach them to use good debugging techniques. Depending on the sophistication of the particular incubator company they might invest in mentoring patterns and performance to help the student be more productive for them but often debugging is the first investment.

Left to the traditional cs classes the students don't seem to walk away with the same set of skills that help them narrow a problem, manipulate the data while the program/service/page/site/component is running andreally understand the implications of what they've written vs. what they needed to write to make it right.

I went to Rensselaer and I 'learned on my own' because I was paid flat rate for some projects and I wanted to minimize my own time spent on programming - and it was further enforced by working as an intern @Microsoft in 1994 where I got to see how useful an Integrated Dev Environment really was.

Wagering a hypothesis based on my experience as a TA and aspiring CS prof:

It would actually confuse the kids who have little to no programming experience more than it would help.

Now first of all: I completely agree that teaching how to use a debugger would be a great thing, but I think the barrier to doing so stems from the greater, systematic problem that software engineering and computer science are not separate majors. Most CS programs will require 2-4 classes where learning to code is the focus. After these, coding ability is required but not the topic of the class.

To my main point: It's very hard to teach something using the guise of "you don't get this now but do it because it'll be useful later." You can try, but I don't think it really works. This as an extension of the idea that people only really learn from doing. Going through the motions but not understanding why is not the same as doing.

I think kids learning to code for the first time aren't going to understand why using a debugger is more effective than inserting print lines. Think about a small to medium sized script you code: would you use the debugger barring odd behavior or some bug you couldn't work out quickly? I wouldn't, seems like it would just slow me down. But, when it comes to maintaining the huge project I work on every day, the debugger is invaluable beyond a doubt. By the time students get to the portion of the curriculum that requires big projects, they're not in a class that focuses on general coding anymore.

And all of this brings me to my awesome idea I think every CS prof should do when teaching how to code: instead of exclusively asking for projects from the kids, every now and then give them a big piece of complex code and ask them to fix the bugs. This would teach them how to use a debugger

In high school we were taught to debug by writing stuff out to the console.

In college, we were taught a mix of that plus using a debugger.

The tools have only gotten easier to use, so I am really not sure why it is not taught.

I was taught in my first CS class how to use a debugger. It didn't do me much good to be setting breakpoints and stepping through my code when most of what I wrote was "Hello World!". I pretty much ignored the debugger from that point on until I learned to use GDB in a much more advanced course while working on a "binary bomb" homework assignment.

Since I've been out of school and working I've spent a lot more time using a debugger and learning how useful it can be. I would say that learning to use a debugger includes three things - a need for one, being taught/learning how to use one, and experience knowing how to use one to your advantage.

Also, spending some time learning "echo debugging" can be worthwhile for those situations when a debugger isn't available/necessary. That's just my $0.02.

There are more than a few questions here, to my mind. Here's a few that are asked and a few that I'd infer:

I was taught in BASIC and Pascal initially, usually with an interpreter that made it easier to run the program till something blew up. We didn't have breakpoints or many of the fancy things there are now for tracing through code, though this would have been from 1983-1994 using a Commodore 64, Watcom BASIC, and Pascal on a Mac.

Even in my later university years, we didn't have a debugger. If our code didn't work, we had print statements or do manual tracing, in terms of time this would have been 1995-1997.

One cavaet with a debugger is that for something like Visual Studio, do you have any idea how long it could take to go through every feature it has for debugging? That could take years in some cases I think. This is without getting into all the build options and other things that it can do that one might use eventually. Another point is that for all the good things that a debugger gives, there is something to be said for how complex things can get,e.g. using a breakpoint in VS there is the call stack, local variables, watch windows, memory, disassembly and other things that one could want to examine while execution is halted.

The basics of using a debugger could be learned in a week or so, I think. However, to get to the point of mastering what a debugger does, how much goes on when code is executing as well as where it is executing as there are multiple places where things can run these days like GPUs to go along with the CPU, would take a lot longer and I'd question how many people have that kind of drive, even in school.

You're question is kind of similar to, "Why aren't students taught software testing"? I'm sure the do in some places, but typically Universities/Colleges stick to teaching the 'interesting' theoretical computer science stuff, and tend not to teach the practical tools. Like how if you're taking English in school they teach you how to write, not how to use MS Word (yea I'm sure there are some Word courses, but you get my point).

I wasn't taught to use a debugger in my undergraduate degree, because you cannot use a debugger on a deck of punch cards. Even print statements are a luxury if you have a 15 minute turnaround on "jobs", etcetera.

I'm not saying that people should not be taught to use debuggers. Just that it is also important to learn to debug without this aid, because:

1. it will help you understand your code better if you don't have to rely on a debugger, and
2. there are situations where a sophisticated debugger won't be available.

On the latter point, I can also remember debugging a boot prom on an embedded device using a (rather expensive) logic analyzer to capture what was happening on the address / data lines.

The same reason students aren't taught version control, or unit testing, or shell scripting, or text editing, or documentation writing, or even (beyond intro courses) programming languages. The class is about computer science, usually a single concept or family of concepts, not programming. You're expected to learn what you need.

This isn't unique to computer science. My chemistry classes (I also have a chemistry degree) didn't teach me how to use any chemistry lab equipment, either. You learned that by hanging around in the lab and watching other students and asking the grizzled old profs who hung out there.