Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
How to ruin Linus's vacation
Posted Jul 20, 2011 0:26 UTC (Wed) by neilbrown (subscriber, #359)
The common pattern that I find in "bugs that make no sense" is that I am believing something that isn't true. Once I identify and challenge that belief, the bug becomes obvious. The reason that these bugs are harder to find in my own code is because I believe my code is correct (in general, and in lots of specifics), so I don't question it so closely. When I'm reading other people's code I have less belief that it is correct, so less hindrance to finding the bugs.
Put another way: finding a bug in my code is both a success and an admission of failure. Finding a bug in someone else's code is pure success. This sounds like a strong case for pair-programming!
Posted Jul 20, 2011 2:25 UTC (Wed) by elanthis (guest, #6227)
It's also why "check your assumptions" is the first rule of debugging I teach to new coders. :)
Posted Jul 20, 2011 2:44 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
This is also why I find debugging with print and assert statements to be much more helpful than single stepping, in the vast majority of cases. Single stepping was more useful to me when I didn't necessarily understand all the language constructs. That was 20-25 years ago, though.
Nowadays, if I have some weird bug, it's because something I think is true is not, or some other "invisible-to-me" error. A judiciously placed print statement (perhaps guarded by an 'if' to filter out the noise) makes it easy for me to prove or disprove my assumptions about what's happening in the code, though, without disrupting any of the code around it. I can compare working cases to non-working cases easily and in a batch-wise manner after the fact. Very useful.
Posted Jul 21, 2011 19:19 UTC (Thu) by nas (subscriber, #17)
Posted Jul 22, 2011 19:58 UTC (Fri) by smurf (subscriber, #17840)
Please enlighten us what this test means; not everybody is damiliar with the idiom.
Posted Jul 23, 2011 9:45 UTC (Sat) by smurf (subscriber, #17840)
Posted Jul 23, 2011 21:38 UTC (Sat) by neilbrown (subscriber, #359)
Pick the wikipedia link on Rubber Duck Debugging.
Posted Jul 25, 2011 18:08 UTC (Mon) by Lennie (subscriber, #49641)
I presume the name comes from working late because you can not figure out a problem. Then the janitor comes and he can sees you are kind of frustrated and asks what the problem is.
You try to explain it to the janitor in simple terms and then you understand your problem and can fix it.
Then you go home happy I guess.
The ducky is just a way to try and induce that state of mind with an inanimate object where you are trying to explain the problem to someone else in simple terms.
Posted Jul 21, 2011 8:34 UTC (Thu) by dgm (subscriber, #49227)
"Oh Lord it's hard to be humble
when you're perfect in every way.
I can't wait to look in the mirror
cause I get better looking each day.
To know me is to love me
I must be a hell of a man.
Oh Lord it's hard to be humble
but I'm doing the best that I can."
-- Mac Davis
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds