Firstly, I'd like to know what does the term "debugging
skills" constitute of, exactly?

Certainly it isn't about knowing the "commands" of GDB.
I won't consider knowing the commands of GDB "a skill".

What should be an idle approach to debug someone else's
code?
How do you improve yourself as a debugger?

Finally,
How to know whether you have excellent debugging
skills or not?

Not clear what "an idle approach" is but to debug someone else's code you would need to understand which part of the code is generating the bug symptoms. Sometimes that is all that is required; the defect becomes obvious on inspecting the code. For more intransigent bugs you would also need to study the code and the data structures sufficiently to identify how and where the intended data changes differ from the actual.

Sometimes there are shortcuts like knowing that the bug has appeared recently and the recent code changes. Or the inputs have changed ...

Improvement by practice and critical self observation? By noting which techniques were effective and which not? By working with others and learning their techniques?

Excellence? When you are asked to do it repeatedly -- or maybe that just says your colleagues won't do it

2 members found this post helpful.

Agree with all of this...well said, catkin.

I think debugging starts with good coding. Code in a such a way that it prevents you and others from making mistakes.

Use functions that are not prone to buffer overflow. Do plenty of bounds checking on input. For conditional statement I always put the constant on the left of the '==', just in case someone changes it to '=', by mistake or maliciously as was seen in a recent kernel bug. Use assert to test variables before using them in calculations. In cryptography many developers include the size of the type in the name of the variable to make sure you're not mistakenly using the wrong function on a type of the wrong size. You should do this when the type size matters, and I recommend using 'stdint.h' when type size matters. I use these for everything but counters if I know the counter is not going to overflow in any situation. Turn on all compiler warnings. Learn how to use gdb, which is helpful in case you have a large program and have no clue where the error might be, it can tell you exactly.

The reason I asked this question was that I saw in a job
advertisement the following as a requirement:

"excellent debugging skills"

Question framed differently:

How, in an half an hour interview, you'd judge whether the
candidate has some debugging skills or not?
In this thread I am talking about debugging someone else's
code with which you are NOT familair.

Actually "excellent debugging skills" itself has no any meaning, it depends on the language, platform .... 30 years ago I reverse-engineered games written for Commodore 64.
20 years ago I have remote debugged shared libraries loaded runtime on HP-UX (that was our own C++ code).
Is that ok for you?

That would be the CV, and if you were really interested just ask him/her to tell about his/her adventures. Probably he has an exciting story related to debugging...

1 members found this post helpful.

Didn't know that it would matter so I didn't mention
that it was for C++ on Linux.

If you are the goto person in your group for debugging, then and only then you will have the debugging skills.

Time was (before the advent of large, standard packages), most programmers got to actually debug once in a while (during the support phase) or often (during the development phase). Then it was all about good understanding of what the program should do, ability to browse the code and zero in on the problem segment, suggest test data and integrate the code into the next release etc.

Now with packages, I suspect that the core programmer is now dumbed down to a coder who codes to very detailed specs and is given less leeway. Debugging would be done by the seniors (or toolsmith, tester or language lawyer in Brooks "Mythical Man Month"). These skills needed would be a full knowledge of the requirement, environment, tools and proper (and by elimination what is improper) language constructs. If you are good at these, you have the skills.

OK

I spend a lot of my time debugging the hardest problems from other engineers' work. I'm very good at it.

Most of it is the ability to think. Rely less on what you know or think you know and rely more on deductive ability, intelligence rather than knowledge. Experience and knowledge can also help, but not if they are all you rely on.

In almost all the debugging I do, the engineer who previously tried to debug the problem knew more about the topic and the algorithm, not just more about the code he wrote. Most engineers rely too much on knowledge when thought is required.

To debug effectively, you need to be able to quickly form plausible theories from very incomplete evidence and quickly figure out what to look at that would support/refine the theory, or more often disprove the theory giving you the basis for a new theory. In a consulting job years ago, I worked closely with a technical hands-on boss, who very much appreciated the results I achieved trouble shooting the work of the full time employees he managed. He frequently commented that it was a flaw in my process that I formed theories too early with too little evidence and was usually wrong. But that is the process. A good "wrong" theory is the right tool for guiding an investigation and gets you to the right answer a lot faster than just gathering evidence without a theory. Of course you need the confidence and personality to avoid confirmation bias. Never try to defend a theory. You might need to argue in favor of a theory to get support from others in a large project for the effort needed to investigate the theory. But investigating a theory still must be attacking it, not defending it, even though it is your own theory.

I can't imagine how one might do that. Even though I have that skill myself, I would not know any way to measure it in an interview setting. Most interviewers are even further from being able to measure that skill because they don't have it themselves and would misunderstand it even after seeing it in action.

I couldn't disagree more. "Excellent debugging skill" is independent of not just the language, but even the discipline.

I have no training and not much knowledge in circuit design, but in previous jobs and consulting positions I was very effective at debugging the hardest problems in complicated circuit design work done by experienced knowledgeable engineers, who were not able to debug those problems in their own designs themselves.

In my current and previous jobs, I have debugged programming problems in languages I didn't know in algorithms based on advanced mathematics that I don't know.

Relevant knowledge and experience is ALSO very helpful in debugging. But it is never enough, while debugging skill and raw intelligence often is enough. Most of my recent debugging has been in C++. In debugging hard problems in C++, I rely on a solid knowledge of the underlying assembler language. I started debugging hard problems in C++ before I learned C++ or could code in it. So I needed to look at the generated asm code to discover what the C++ code meant. I'm now a very experienced and skilled C++ coder. But I still look more at the asm than at the C++ when debugging any difficult C++ problem. It is far too easy in C++ to code something that looks very much like it means one thing, but really means another. It may be rare (across all our code) for an instance of that to be tricky enough to fool a C++ coder at my level. But I'm debugging problems that were too tough for other experienced C++ programmers before I ever looked at them. So the starting point is the fact that something unusually difficult is involved.

1 members found this post helpful.

IMO Debugging -ne Troubleshooting

Debugging is the act of looking for 'bugs' or processes in a program/computer that aren't doing what they are intended to do. Bugs get there by programmers that mistakenly put bad code in, don't test, or don't have sufficient time to test the impact of code on the many other facets of the program. It's usually unforeseen.

Troubleshooting is "My car won't start, Ill check the gas, then the battery, then the fuel lines." And the problem is BOUND to happen. It's mechanical. And that basic troubleshooting process never changes.

With code, if you see the cursor disappear, it could be any of a million lines of code, in a hundred different files or subsystems.

What makes you a good "debugger"?

Let me answer this way: What makes you a good doctor? What makes you a good physicist? Education, training, and practice.

Additionally, It should be said that you can be good one place and not as good at another. For example, I've worked where I work so long that I can debug any of the C or PHP crap that we have lying around usually within the day. But a quick jump onto the Fedora site, looking at a bug for a cursor, I can tell you that without further training, and knowledge of the system, I'm not going to be as good at debugging it.

1 members found this post helpful.

The way I'd view it, is I'd want to see how the candidate thinks about a problem. How they'd troubleshoot it, and what steps they'd take to figure it out. There isn't going to be a 'right' answer, in my opinion. I'd look for more than just the canned answer about running things through a debugger, and focus on the thinking that leads them there. Did they check obvious things first? (log files, running the program in verbose mode/foreground, check other processes that the program depends on, etc.) I look for flexibility in thinking, rather than someone who just knows one way to view every problem.

1 members found this post helpful.

As a job seeker, that kind of line in a job ad is a red flag. At best it makes the job seem like a temporary one. At worst you get to look bad making a terrible system less terrible.

As far as a good debugger. Knowing the system that is buggy. Knowing the languages used. Knowing the debugging software. And make no assumptions, actually verify that everything works as advertised. Also know the differences between the development and production environments.

Consider the following program:
This program is supposed to print a copy of Lincoln's Gettysburg Address. (That's what the consultant who sold it to us for $50,000 promised it would do.) But it is taking too long to complete. Using only the GDB debugger, make it do so. Before lunch, please.

Rule Number 1. Fix more than you break.

'His debugging skills are exceptional.'
http://www.cartoonstock.com/directory/d/debugging.asp

;-)