Possible Duplicate:
Are debugging skills important to become a good programmer?

I'm a young Java developer and I make a systematic use of the Netbeans debugger. In fact, I often develop my applications when I debug step by step in order to see immediately if my code works.

I feel spending a lot of time programming this way because the use of debugger increase execution time and I often wait for my app to jump from a breakpoint to an other (so much that I've the time to ask this question).

I never learned to use a debugger at school, but at work I've been told immediately to use this functionality. I started teaching myself to use it two years ago, and I've never been told any key tips about it.

I'd like to know if there are some rules to follow in order to use the debugger efficiently.

I'm also wondering if using the debugger is eventually a good practice? Or is it a loss of time and I've to stop now this bad habit?

  • 4
  • If you finish your work assignments earlier than you would without a debugger, it has an effect.
    – user1249
    Commented Feb 16, 2012 at 15:27
  • @ThorbjørnRavnAndersen In other words it's mostly an intrinsic issue. Commented Feb 16, 2012 at 15:38
  • You've never been told any tooltips?
    – JoelFan
    Commented Feb 16, 2012 at 15:38
  • 4
    Yes, this is very inefficient. This approach forces you to think about the code as a sequence of steps. Thinking in such an imperative manner will obscure your understanding of higher level abstractions, and could potentially make it harder to grasp the declarative paradigms.
    – SK-logic
    Commented Feb 16, 2012 at 18:25

13 Answers 13


It affects the efficiency in a very good way.
I feel that it's used too seldom by developers.

Not only is it good for debugging but it can also give you an insight in profiling.
For example when line stepping you can feel "ahh" this line took a little too long time to execute and you get a feeling for where the bottlenecks in your app are.

  • 1
    Yeah right! That often append, by the way I prefer use Netbeans Profiler for this kind of issue. I've noticed that step over lines time is not always significant. Commented Feb 16, 2012 at 14:48
  • 31
    Properly written and unit-tested code should seldom require stepping through it with a debugger, and I'm skeptical that pauses in the debugger will tell you anything meaningful about bottlenecks in your code, given the overhead the debugger itself imposes. Debuggers are valuable tools, but stepping through code with a debugger is extremely time-intensive in non-trivial code, and should only be undertaken when other methods (like reading the code and examining the results of unit tests) fail to achieve results. Commented Feb 16, 2012 at 17:24
  • 5
    Totally disagree. One must learn to think of the code as a whole, see the high level abstractions behind trivial constructions. Do you still read by syllables? Probably not. Thinking of a code as a sequence of steps is comparable to reading aloud by syllables. Good for 4 year olds, totally nonsense for the more mature programmers.
    – SK-logic
    Commented Feb 16, 2012 at 18:28
  • 4
    While I disagree with the example you gave (debugger execution time is rarely relevant) I do agree that sometimes it can give you insight into slow methods. I've more than once been stepping in the debugger only to find that a method I thought was executing once was executed multiple times. It's often hard to catch things like that without littering code with print statements. Commented Feb 16, 2012 at 19:36
  • 1
    @RonWarholic In order to know number of method executions you can use profiler it's easier than use print statement or the debugger. I use Netbeans profiler, it give also the execution time per method, memory use, heap, etc... Commented Feb 17, 2012 at 8:33

Debugging eats up time since you are executing code a billion times slower than you would in a unit test. Often there is a better tool for the job: microbenchmarks, performance profilers, unit tests, logging, or just reading the code. With a suite of unit tests you can execute dozens of code paths in milliseconds, which would take hours in a debugger.

I rarely debug when I can write a unit test. That way, you have a record in the form of an executable test of how the code works. If you simply debug, that knowledge is only in your head until you forget it.

When you have to debug, specific tips would be to learn the step over/into/return hotkeys for your debugger, how to inspect variables, and use conditional break statements.

  • But for the sake of saving the tester's time and effort, it would be best to use the debugger as and when required. Essentially speaking Unit Testing is infact a developer's job! What do you say?
    – Maxood
    Commented Feb 16, 2012 at 14:35
  • 12
    I'd argue that having good unit test coverage and using a debugger are orthogonal to each other. Unit tests help me to manage change, but they are of only moderate help in learning a new code base, and they are of no use in tracking down bugs that only occur at runtime. And logging statements, while they inarguably have their uses, are really only applicable to situations that you think of in advance. Commented Feb 16, 2012 at 14:43
  • 1
    @Adam Crossland With a debugger you can do white box and black box testing conveniently. You can spot a memory leak, undesired ouputs and can also validate your methods correctly. This ultimately helps to avoid bugs at runtime. Can you justify your argument?
    – Maxood
    Commented Feb 16, 2012 at 14:51
  • 3
    @Adam, they are orthogonal in some areas, certainly. I'm all for picking the best tool for the job. However, unit tests can often prove things about the code faster than debugging. For performance profiling I use jvisualvm or microbenchmarks. It's been a long time since I used a language without managed memory, but I do remember using the debugger more often in C++/Assembly. Commented Feb 16, 2012 at 15:08
  • 2
    @mcmcc No, normally I understand the code I've written. However when something unexpected happens and I can't deduce why by reading the code then I typically write a unit test or a logging statement. When that fails I debug. Most of the time I don't reach that point. My code is well-refactored and not very algorithmically-intense, YMMV. No need to be rude. Commented Feb 16, 2012 at 21:40

Just my opinion, but I feel that regular, systematic use of a line-level debugger might be the single greatest productivity enhancement practice that a programmer has available. Whether you are jumping into and trying to learn an existing code base or just trying to get your own code working, get thee into the debugger and start Stepping.

You are fortunate, I think, to work at a place where you are encouraged to learn and use a debugger. I have seen far, far too many working, veteran programmers who just never learned to use an invaluable tool.

  • Downvoters: any specific objection? Commented Feb 16, 2012 at 17:08

Some zealots out there might claim that debuggers make you lazy, or that you should just write a unit test for everything. For those of us that have to actually get stuff done, a debugger is an essential tool in quickly troubleshooting/exploring code. Of course test coverage is great, and will let you know what your code is doing, but sometimes you just need to get into the thick of it and see what's going on.

  • 5
    Such zealots clearly don't understand that debuggers and unit test coverage are two different tools that solve two different problems. While I am excited about and grateful for the somewhat recent growth in emphasis on unit tests, they are not and never will be a panacea. Commented Feb 16, 2012 at 15:01
  • 7
    The tools are often complimentary. Suppose you have a unit test which is not passing, and it is not clear why it is not passing. You can fire off your unit test, while running the debugger! In this case the unit test acts as a convenient way to set up preconditions and get into the code that needs debugged. The debugger will then help you find and fix the problem which is causing the test failure.
    – Freiheit
    Commented Feb 16, 2012 at 15:40
  • Neither tests nor interactive debuggers could help to write better code. A dense, highly abstract language with a strict type system is much better. Literate programming is much better. Smart logging, properly placed assertions and/or contracts are better. Interactive debugging is for kiddies.
    – SK-logic
    Commented Feb 16, 2012 at 18:32
  • @AdamCrossland & Morgan: I've been considered such a zealot in the past, but it's with good reason (and it has nothing to do with unit tests!) - Going straight to the debugger first makes you lazier mentally. If you can run the code in your head, you can also recall it much easier and gain an instinctive knowledge of what could have gone wrong any time you see a new error. This does not mean I refuse to use a debugger, however.
    – Izkata
    Commented Feb 16, 2012 at 19:47
  • 2
    @Morgan I actually have to get stuff done, which is why I spend as little time debugging as possible. I find the feedback to time-spent debugging ratio to be very low. Commented Feb 16, 2012 at 21:43

I really, really wish our last developer used a debugger. We had a PHP site with a framework with lots of good debugging features, he used none of them. Since the code was PHP and there were no compiler errors, he apparently merrily mutilated his code until it worked at run time.

Every single page output dozens of warnings or errors when in debug mode and if he bothered to read debug output or line-by-line analyze what his code was doing, much of this could have been avoided. Rather than use a debugger he used manual code to write variables to a .log file on the server. He left that code in production; the log files were 8 GB by the time I got to them.

You might spend more time walking through your code, but you'll spend less time trying to fix it. You'll write better code as well, and it will help you understand your own code, making you a better programmer period.

  • +1 for the time spent on fixing the code. In terms of performance, debuggers may show more time is spent on the code than in actual environment though. I have seen a few examples of this. So profiling should be done separately.
    – arin
    Commented Feb 16, 2012 at 15:57

Using a debugger is fine when something fails, or when you don't understand what some legacy code does. Using a debugger when nothing fails, just because you don't understand what your own code does (the lines you have written the last 10 minutes), is IMHO a very bad practice. In this case you could improve your productivity much more by investing time in writing your code in a more readable or understandable manner instead of debugging, or by writing some automatic tests.


Using the debugger undoubtedly increases your efficiency, since it allows you to do things that would be difficult or impossible to do without it. It is way more efficient to eval expressions on the fly, change local variables etc. than to pre-guess what you might be interested in and write the corresponding printf statements, and to sift through the output for exactly what you want to know.

However, it might indicate that you have other problems - you would normally like to be able write routine code without having to step through it attentively even once, since it's the result that counts rather than the details, and that can be asserted via unit tests. However, that is a matter of personal preference. You may very well be much more productive with your exploratory style than your co-worker with their test-driven style, and vice versa.

  • Thanks for the answer. I don't always write my code debugging step by step ofc, but for complex algorithm (for example I made a cobol analyser in Java) I've use this method in order to access the hundreds of arrays that contains different kind of data. And also very often to test my long patterns :) Commented Feb 16, 2012 at 14:40

Debuggers are just another tool. It can really help your understanding of programming when you are starting out, and it can simplify hard problems at times.

There is also a logic portion to solving problems--many problems involving threading or the interactions of systems can be difficult or impossible to trace with a debugger--for those you may need different tools--working on your problem solving skills NEVER hurts.

You know one thing I've learned over the years is that everyone who is proficient in a skill thinks they know 90% of what they need to know--the problem is that people typically can't know what they don't know (if they saw something they didn't know, they would go and learn it!)

Why do I add that? Well I've seen developers who can solve most problems without a debugger much quicker than it would have taken to bring the debugger up. Over-reliance can slow you down if that's the very first thing you do every time.

It's like learning on the keyboard--if a beginning typist had to type on a keyboard without letters he'd think it was obvious that having letters was better--but then you reach a point where having the letters removed can make you significantly faster (By teaching you not to look at your hands), and finally you reach the point where it's completely irrelevant if the letters are on the keys or not.

In programming some people reach that last stage where the debugger just slows you down, but there are probably more at a point where having it taken away might boost their analysis skills significantly--yet most people are probably in the first stage where you just flounder without it.


At work, using a debugger increases programmer's efficiency. At school, you can spare it as it is good to dry-run the algorithm of your programming code yourself to get the correct and desired symantics.

Debugger is an efficient and useful tool for programmers. You cannot avoid it at professional level.It is good for you to learn using a debugger yourself for your programming environment as this will greatly help you to save programming time and effort. So using a debugger is a good programming practice at work!


Obviously a debugger is invaluable for understanding your own and other developers code. However, don't lean on it! For bottom-up approaches, you generally should try to find a proof that your code is doing what it should do. Multi-threaded code generally is hard to debug, especially when you have problems with deadlocks/lifelocks/starvation. I feel it is one of the prime reasons why many die-hard programmers find it so hard to write multi-threaded code, as they don't have their most 'valuable' tool to their disposal.

I use a debugger as a last resort and generally only in unstructured code, when a proof is hard to find.

The things you should lean on are:

  • Prevent state (the prime reason why you need a debugger)
  • Prevent complex code paths (another reason)
  • Use unit-tests (find bugs earlier)
  • Try to find a proof that your algorithms are working the way the do
  • Document the pre- and post-conditions of your methods (
  • Peer-review your code

These should give you trust in the things you're writing.

  • "Obviously a debugger is invaluable for understanding your own and other developers code. " Invaluable for understanding what the code does, vs. what it is supposed to do, vs. what you thought it was supposed to do.
    – gnasher729
    Commented Sep 14, 2017 at 23:14

While I rarely write Java code these days, I rely on Python's ipdb library (or Werkzeug HTML/AJAX-based debugger shell) to gain access to an interactive environment where I can manipulate objects in that given stack frame.

It's often an invaluable tool for exploratory programming.

With Java (mostly under Eclipse), I tend to use watches and the debugger more or less the same way, to explore the machine state on any given program point and try to gain some understanding from it. I really thing it helps me being more productive and to understand other people's code better.


You should be able to reason through the code without the use of a debugger. It's good that you're using it though and yes it does have an effect. Sometimes it's faster and more efficient to run through the code and see how it changes things rather than to puzzle it out just by reading the code.


I think that it is a very good practice and somewhat a replicate of the test-driven approach. By way of immediately stepping through the code, the programmer is unit-testing it himself.

However, I also think that the programmer should have confidence in the code that he has written and should not write code that he does not trust to see how it behaves within the debugging environment. That, for sure, will lead to inefficiency.

Moreover, do not forget that there can be environments where you might not have the capability to run the debugger. I had an issue where I had to work on a code base that I did not have the luxury and time to set-up the debugger for. The code just had to work. Thankfully it was a small area for the modification and thankfully it worked.

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