Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 11 down vote favorite
2

If experienced programmers actually ever use debuggers, and if so under what circumstances. Although in the answer to that question I said "months" ago I probably meant "years" - I really don't use a debugger. So my specific answerable question is under which circumstances would you, as an experienced programmer, use a debugger?

share|improve this question
81  
Of course they do. Are you high? – wdm May 21 '11 at 16:49
12  
It's like asking if experienced programmers are using keyboard... I don't understand what experience has to do with it - do you think they're Gods and create perfect- working code without errors from beginning? And even if so what does it mean to you - will you stop using debugeer when you need and star saying: "I don't use debugger so I'm reaa programmer"... :) BTW. I doubt any professional will answer such a question... – mj82 May 21 '11 at 16:53
13  
Real programmers, of course, use butterflies – Rein Henrichs May 21 '11 at 18:49
4  
Most existing debuggers are old-fashioned, have crappy interfaces, and require the programmer know and understand concepts and paradigms that are difficult to master, and, nowadays, not fair to expect most programmers to use or know. As a result, most modern, experienced programmers, go to great lengths to learn the skills necessary to write the kind of code that rarely ever has to be debugged in a debugger, to avoid the pain of the experience. So "yes they use it" and "as little as possible" – blueberryfields May 21 '11 at 22:00
5  
Experienced programmers who "don't use debuggers" are probably thinking in terms of gdb/SoftICE, and have never used an actual integrated-debugger (and probably don't use an IDE for that matter). They are so far behind the times it's painful. – BlueRaja - Danny Pflughoeft May 31 '11 at 21:23
show 14 more comments

migrated from stackoverflow.com May 21 '11 at 16:56

closed as not constructive by Steven A. Lowe, Walter, Macneil, Rein Henrichs, Anna Lear♦ May 21 '11 at 19:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

15 Answers

up vote 32 down vote

I would say that not using a debugger is a sign of inexperience. Stepping through code line by line is the best way to trace the flow of execution.

share|improve this answer
29  
strange then that after over 30 years of programming in assembler, fortran,, C, C++ etc. etc. I feel no desire to use one. – Neil Butterworth May 21 '11 at 16:56
44  
Doing something for a long time doesn't necessarily make you good at it. – ceejayoz May 21 '11 at 17:03
22  
Not being able to use a debugger is a sign of inexperience. Understanding the flow of a program by just reading code isn't. Of course, experienced programmers will need the debugger once in a while, but if you can read the code, there is no need to, and it won't make the process of debugging any faster either. – GolezTrol May 21 '11 at 17:03
9  
@Karl Bielefeldt: Let me name a couple of famous examples of programmers who don't use debuggers for debugging. Linus Torvalds, author of Linux. Larry Wall, author of Perl. Complex enough software for you? – btilly May 21 '11 at 21:14
7  
@Neil: how much of your time do you spend working on your own code, and how much maintaining code written by other people? And in particular, how much maintaining code written by other people who should never have been allowed anywhere near a programming language? – Carson63000 May 21 '11 at 21:44
show 9 more comments
up vote 26 down vote

I use the debugger often, because I work on a large system and therefore I suck. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

No matter how short and frequently-read your code is, there is always going to be a possibility that it will have bugs. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

To err is human and one can never prove that a program is correct, so why not use tools such as debugger / automated testing to aid ourselves in this difficult business?

If the code is short enough, then simple tests will do. Also, if it is short and you know the nature of the bug, the reading the code can be enough. However, once the code base is large, involves several languages mixed together, plus 3 tiers, then you simply must have good test coverage on many levels plus a very good debugger - otherwise you will be wasting a lot of time.

So, when do I not need a debugger?

I am not the smartest coder, nor the most experienced, but still, sometimes I do not need to use the debugger. That is when:

  • The code is mine or well-written AND
  • It is written in a readable language AND
  • The overall project is small.

When do I rely on a debugger heavily?

  • Short Answer: often.
  • When an application crashes. Particularly when it is deployed. Having VS2010 installed on that computer can make a difference between "Unknown Error" and FileNotFoundException.
  • When a 3rd party library crashes or misbehaves.
  • When the code is poorly written. Particularly if the same file was touched by 10 different people in the last 10 years, 7 of which are no longer with the company.
  • When the project is large
  • When the code is rather monolithic.
  • When there are several tiers (GUI, SQL, BL) involved.

Note that "debugger" can refer to more than one tool. I use Visual Studio debugger, SQL debugger (mostly for stored procs) and SQL profiler as well (to figure out which SP are being called). Would I need tools of this caliber I were writing a quick sysadmin-ish Python script? No. If I made my own little GUI-based tool? Depends. If it is .Net WinForms - probably not. If it is WPF - yes.

What defines a "real" programmer anyway? One that is quick? knowledgeable? Is good at algorithms? Writes good documentation? Just when exactly does one graduate into this new title? When does one cross the magical line?

I would say that a programmer who has not gotten his/her hands dirty in an existing 100+ man-years effort has not had a chance to be humbled by the complexity and own limitations (as well as frustrated with code quality).

I personally try to use the best debugger available to me, and I tend to use it often. If a task is simple enough and does not require a debugger - I do not use it then. It does not take too long to figure whether I need one or not.

...

Now, in theory I could read the code base for so long, that I would just get it. However, hands-on approach works best, plus I often want to re-write that stupid code that I am seeing. Unfortunately it would take me 10+ years to clean up the code base that I am in. So, using debugger is an obvious first step. Only when I find out just which one of 5 million lines of code is acting up, would I scan the file up and down to try to figure out what that class is doing.

share|improve this answer
+1, excellent answer, I particularly agree with the "when there are several tiers involved" aspect, that's one that is seldom mentioned by the "just read the code and find the error" advocates. – Carson63000 May 21 '11 at 21:46
Glad you could read the whole thing. – Job May 21 '11 at 22:53
+1 for great answer and for examining the definition of a "real programmer". Use of this phrase made the OP sly, interesting, and potentially inflammatory (because of denigrating implication or innuendo). – Smandoli May 25 '11 at 13:28
1  
"one can never prove that a program is correct" That's not true. – GManNickG Jun 9 '11 at 11:05
1  
@GMan, please do elaborate on your statement. As I have learned, many previous attempts to prove correctness of short snippet of code for a specific language have failed, e.g. several bugs have been found after the proof was completed (by a professor specializing in such proofs). Some very trivial programs could be proven to be correct, I suppose. I am curious to find out your angle here. – Job Jun 9 '11 at 18:12
show 1 more comment
up vote 13 down vote

"I don't like debuggers. Never have, probably never will." — Linus Torvalds

On the other hand, he doesn't have a Stack Overflow account, so I'm not sure if you are interested in his opinion :)

share|improve this answer
2  
Not many of us are Linus Torvalds, for the rest of us mere humans we need the debugger. – Steven Ellliott Jr May 21 '11 at 18:54
6  
kernels don't lean well to debuggers. – user1249 May 21 '11 at 22:56
5  
Yeah, kernel programming is a different field than userspace programming. I don't typically agree with Linus's opinions for userspace, but they are definitely respectable when dealing with kernelspace. – alternative May 22 '11 at 0:22
9  
"I don't like debuggers" doesn't mean "I don't use debuggers." What Linus actually said was "I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program." (I know some will try to twist that to mean that Linus doesn't use a debugger, but that's not accurate.) – Kristopher Johnson May 24 '11 at 21:16
5  
It seems like Linus Torvalds and I never agree on anything. – BlueRaja - Danny Pflughoeft May 31 '11 at 21:14
up vote 9 down vote

So my specific answerable question is under which circumstances would you, as an experienced programmer, use a debugger?

  • When you're unable to "debug" by reading your code.
  • When you're unable to predict what values certain variables have an a given time.
  • When your mental model of your code does not fit the output given by your code

Edit:

I had the fortune/misfortune of not knowing how to use a debugger in my programming journey. Thus in the past I was forced to debug without a debugger. However after learning to use a debugger -> I've become 100x more productive in finding bugs.

share|improve this answer
+1 for "When your mental model of your code does not fit the output given by your code" – user Aug 12 '12 at 15:40
up vote 7 down vote

I think experienced programmers almost exclusively use debuggers, when they are needed. What better way to track down a bug than to actually follow the execution of the code...

Are you under the assumption that the Skeets of the world don't make mistakes or just know everything? All but the most trivial programs behave in unexpected ways under some circumstances. It is a given that issues are going to have to be investigated. So the choices are use print statements, on one end of the spectrum, or look examine what happened, post mortem, on the other, or look right in the middle as the code executes and figure out what is going on.

Maybe a better way of thinking about it is that experienced programmers know when to use a debugger. In code with few dependencies looking at a stack trace is probably enough to figure out what is wrong. But there are complicated scenarios where your code is working with other code, and you need a debugger to look at the stuff you didnt write.

share|improve this answer
2  
Well, this is exactly what I am trying to investigate - I'm an extremely experienced programmer and I never use one. – Neil Butterworth May 21 '11 at 16:49
4  
@neil, maybe you have no need. Rest assured, the time will come where the debugger will be the simplest way to get to the bottom of an issue, whether or not you actually end up using one.... – hvgotcodes May 21 '11 at 16:56
I can read stuff I didn't write too. And if I can't, it is useually because it is bad code. In other cases, I use the debugger. – GolezTrol May 21 '11 at 17:05
If the language you use supports exceptions, and if you're using them + a logging framework appropriately (e.g. log4j or something like that) you'll always end up with a stack trace pointing to the line of your error. 99% of the time it's a null pointer exception where you didn't expect it. What else is a debugger going to tell you? Now, when I was programming in c, there were things that you simply couldn't find without a debugger (e.g. stack corruption). But those types of things just don't happen in high level languages anymore. – Kevin May 21 '11 at 17:07
1  
@kevin, right, i think there is a class of problems between those two where the debugger is the most natural way to get to the bottom of an issue. Maybe I want to see the dynamic properties put on an object in a dynamic language framework like grails. Maybe I want to see exactly where something I think is not null is made null (NPE tells you where the exception is, not why the thing is null). Maybe I want my debugger to pause on exception so I can see what combination of code caused an exception, not just that it occurred in the stacktrace. – hvgotcodes May 21 '11 at 18:03
show 4 more comments
up vote 6 down vote

To give a slightly different perspective from the current answers; As an embedded software engineer working on systems that often have a real-time component I rarely use a debugger.

On occasion a debugger can be an amazing tool and whenever I am able to build and run code on a desktop then I would always use a debugger.

On chip, with real-time constraints, then there is a heavy burden associated with trying to use a debugger. As soon as you pause execution you are likely to upset, possibly fatally, the timing of the rest of the system. Generally on chip, printf in non-critical code and IO waggling in time-critical code is the best and actually simplest tool. It's not as good as a debugger, but it's much cheaper to get working with a real system.

share|improve this answer
1  
you might want to investigate hardware-based debugger boards – Steven A. Lowe May 21 '11 at 18:21
@Steven thanks; unfortunately while some of the systems I work on have suitable hardware support, others do not. While we generally have the option of a logic analyser this tends to be even more expensive in terms of time. – Luke Graham May 21 '11 at 18:44
I'm the exact opposite. I use a debugger a lot more often on embedded systems. I agree about it upsetting the timing, though. It takes a fair amount of effort to filter out and/or minimize the changes caused by putting a debugger in the loop. – Karl Bielefeldt May 21 '11 at 20:34
up vote 4 down vote

I don't, and I've been programming for over 10 years. I used to, when I programmed in c/c++. Now I program in java. The truth is that if you're doing logging correctly you'll end up with a stack trace which is enough for most skilled developers. Also if you're writing (good) unit tests, and functional tests, that eliminates a whole class of bugs.

share|improve this answer
If it clarifies more, I know a lot of java programmers that DO use a debugger. They're mostly right out of school. – Kevin May 21 '11 at 17:01
1  
stacktraces do not show data - you must add that information yourself - but then they are pure gold. – user1249 May 21 '11 at 23:00
1  
@Thorbjørn: They can show data, actually: see Python's cgitb module, for example. (The CGI in the name is mostly vestigial, the original purpose of the module having been to present usable stack traces when a CGI crashed.) Of course, with that, you sometimes get so much data that it becomes difficult to navigate to the stack frame of interest. I love cgitb.enable(format='text') anyway, though. – SamB May 24 '11 at 22:00
I don't really use debuggers and I use C++.. – Nikko Sep 1 '11 at 7:06
@SamB Kevin talked about Java, which cannot to that – user1249 Aug 12 '12 at 17:13
show 1 more comment
up vote 4 down vote

Who cares? What I want to know is will using a debugger prevent me from being a better programmer in the long-run? Maybe debuggers were of lower quality when many experienced developers started so they were a hinderance. Is it a crutch that prevents deeper understanding?

Some programmer, probably better than the rest of us, found a need for a debugger and built one (No idea who created the first one.). I'm sure they were more productive as a result of it. I doubt the motivation was to enable lesser mortals to write code.

share|improve this answer
up vote 3 down vote

Rarely.

Your methods should be small/simple enough to be compiled and run by your mind, unit tests should cover functionality. If you find a bug, write a test. Run it, fix it.

I only tend to use the debugger when ive got unexpected behaviour from untestable code, like the ASP.NET framework.

share|improve this answer
3  
theres some real hater noobs in this thread... – Andrew Bullock May 21 '11 at 16:54
2  
NO reason to down vote this - he's right. – wadesworld May 21 '11 at 16:55
1  
+1 because he's right. – Kevin May 21 '11 at 17:00
10  
-1 because this claim is like saying the way to make money at Vegas is to just win every hand. That doesn't reflect the reality of the situation, and the claim that all code will be simple only exists in small isolated problems. Plus, the "run it, fix it" claim completely ignores how you go about fixing it. I was going to let it slide but then insinuating that all those who disagree makes it worth downvoting. – whatsisname May 21 '11 at 18:35
1  
-1: "Your methods should be small/simple enough to be compiled and run by your mind" is diconnected from reality. That's like saying a function that is longer than 20 lines is too long. Nonsense. – John Dibling May 24 '11 at 19:37
up vote 2 down vote

I use a debugger when I need to. That is not daily, but it does occur occasionally. It is sometimes better to step through the code to see what exactly happens.

I must admit I use debuggers less and less. I've been developing in Delphi for over 10 years. I also write stored procedures in PL/SQL. Since a couple of months, I'm a PHP developer too.

I mainly use the debugger in either of these cases if I find a piece of obscure code that was written years ago and I need to modify it. It sometimes helps to find out the exact way a program works if it is hard to read the code. In PHP that is hardly ever necessary, but in Delphi, which is event based, it sometimes helps when you got a complex framework.

But as you say, using the debugger is an exception. Most problems are solved by just reading the code and fixing any mistakes you (or someone else) made.

But that goes for stepping through code. I do quite often use the call stack when an exception occurs, and I occasionally put a breakpoint somewhere to inspect a variable. But nearly always in a piece of code that needs a thorough refactoring anyway.

share|improve this answer
up vote 2 down vote

In Smalltalk, I develop almost entirely in the debugger:

  1. Write a test that I know will fail.
  2. Run the test. When it fails, the debugger pops up.
  3. Write, in the debugger, the code necessary to make the test pass.
  4. Resume execution.
  5. If I get a green light, go to step 1 with a new failing test. Otherwise, in the debugger find out what I did wrong and fix it.
share|improve this answer
up vote 2 down vote

I occasionally code with no debugger, but only when forced to at gunpoint, ie. legacy embedded gunge on an 8051 or Z80.

IMHO, you need a debugger and logging on any complex job. Once is not a substitute for the other. A logging system cannot help if the app stuffs in a driver, for example, where the only thing the code can do is interact with hardware and set a semaphore.

A debugger cannot help with a system error where the apps are working fine according to the way you wrote them, but the system still doesn't work because of some intermittent comms protocol error.

So, I need the debugger to remove the stupid, glaring bugs and hardware cockups. I need good logging to catch intermittent system integration bugs.

I gotta have both - I need all the help I can get!

share|improve this answer
2  
z80 is big enough for debuggers. CP/M had ZSID. – user1249 May 21 '11 at 23:19
up vote 1 down vote

I only use a debugger when these steps fail:

  1. Get the error reproducible. Think. This is often all that is needed.
  2. Check any stack trace and logs.
  3. Add more logging around the offending code.

These steps takes care of 95% of all cases. That means I rarely use a debugger, and when I do, it tends to give me too much information and I get bogged down in unrelated details. This is especially true if working on a multi-threaded, real-time system.

So judiciously placed logging statements goes a long way.

share|improve this answer
up vote 1 down vote

Could it simply be that very experienced programmers are the same as very old programmers, and they learned to program, and formed their habits, back when debuggers were not always available, and sometimes not very good?

If you get really good at printf debugging (and back in the eighties, we didn't have much choice but to become really good at it), perhaps a debugger doesn't add that much.

share|improve this answer
up vote 0 down vote

It's a question of personal choice.

Honestly I think debuggers are useful in certains situations where it helps a lot knowing what's up on your ram at any given step of your program's execution.

The primary utility of a debugger is to halt a program without the program being designed to halt itself: this feature is quite important.

Apart from those 2 features, I don't think a debugger is really necessary; any complex program you make should have some sort of "verbose" mode, i.e. telling everything it is doing with printf or std::cout, what choices it made, and a lot of other parameters.

Just imagine you make a program, and the user has a problem using it: how to know if he is using it the way it was designed to be used, or if the thing he is complaining about might be a bug?

Debuggers are like the electrical steering for your car: it's more comfortable to have one, but it won't make your drive any better.

Progamming is about design and logic, the way tools can assist you in tracking stuff doesn't make you a better programmer.

Plus debuggers are useful for compiled languages, much less for intepreted ones.

share|improve this answer
2  
I don't understand what compiled vs. interpreted has to do with it. – Michael Burr May 24 '11 at 17:22
good question: me neither. – jokoon May 25 '11 at 11:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.