The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
A software debugger is a last resort, for really tough bugs and really tired brains.
On the contrary! I run the debugger on 90% of the code I write, single stepping through each line to make sure I did it right. Of course I only do that once (unless there's a bug) but given the complexity of LINQ, lambda expressions, closures, and so forth, I find it well worth the effort.
I suppose unit testing could take the place of that, but then I'd have to single step through the unit test to make sure I'd written the test right!
The amusing thing is that that looks quite like one of my wrong versions of FizzBuzz when I wrote this. It's actually surprising the number of code examples I found on the web that didn't implement this very simple algorithm correctly.
Pete O'Hanlon wrote:
So the question is, is this useful?
Absolutely. The whole idea is that even with what looks like the second simplest of algorithms (Hello World) being the simplest) it's easy to get it wrong, and you need to know how to debug it when thinking about even something so simple actually fails.
Pete O'Hanlon wrote:
Is it only a minority that don't know how to debug or is this a wider issue that needs to be taught?
I had a couple debugging session last week with a coworker, granted, a junior dev. What was interesting was that he was looking for the problem in all the wrong places. Before starting a debug session, one needs to ask "what exactly am I looking for and what are my initial guesses at where I might find it?" The "what" is not "where is it crashing" -- the exception tells you that, but the "why is it crashing and what are reasons I can come up with where I can go look?"
So often, I see people trying to understand why the line of code is failing or throwing an exception, not realizing that the line of code is working with data that some other function incorrectly created somewhere else in the process, that probably isn't even part of the function with the failing line.
Pete O'Hanlon wrote:
If it's a minority of developers, then am I wasting my time here?
No, it's the majority. But you're still wasting your time because the majority doesn't even have the awareness that they're approach to debugging is totally wrong. That's what needs to be corrected, and that's where I'd start. With the article title "You do NOT know how to debug!"
I have to agree with you. I can't recall the last time I helped a guy sort out a problem who actually knew how to debug and use the debugger effectively. Everyone I have had to deal with doesn't approach it the right way. That is, assuming my approach is the right way. Historically, it has worked very well for me.
The wildest experience I have ever had debugging code is when I was writing a debugger for a script language I wrote and I was trying to debug the interaction between the script code and my debugger. The script engine generated machine code on the fly so it was a bit difficult to see everything that was going on. The wild part was I had three debugging sessions going on - my debugger was attached to my script process and debugging it, I had a VC++ debugger attached to my script code debugging it, and another VC++ debugger was attached to my debugger and debugging it. That was a real head-scratcher.
In my years of experience, this is definitely lacking in a lot of people I have encountered. Even lecturing at university, I found this to be one of the fundamental issues that prevented students from fully understanding control and data flow.
imho, a majority of posters on QA do not have a clue about how to debug.
I cannot generalize from that to make inferences about other programmers in the main/wild.
I do think that debugging skill is tied closely to mastery of the facilities the IDE offers, and that mastery requires some effort.
I suspect that many QA posters are at the low-end of some general measure of: motivation; eagerness to learn; willingness to work hard to get the "bigger picture." Their questions would never be tolerated on StackOverflow.
So, yes, I think articles from you on debugging would be great.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
If you are going to write an article on debugging, make sure you include the original problem statement.
Many bugs are introduced by misinterpreting the "specs" or by having ambiguous specs.
Another approach might be to show multiple "answers" that all compile correctly, and then ask which of these best meets the spec. (Always have an option "D - none of the above")
I currently have 41 tabs open in Chrome for interesting links that I want to go back to. I rarely do except to look at a link to see if I want to remove it and don't, putting it back on the "look at later" list.
Sometimes (due to my stupidity, not the Chrome browser or OneTab), I lose the links. I feel sad for a few minutes then discover I don't really care.
Sometimes I copy all the links to a "interesting links.txt" file. Not sure where I put the file, so I have several. But I never look at them anyways.
Is there a pill I can take to correct this behavior?