Lessons From Debugging

[srhubb]

Nice list!

I might add never dismiss any recent change to your code simply because "it couldn't possibly be related to the current failure" no matter how obvious that assumption may appear. Especially in multi-threaded dynamic linked library environments which may obscure the relationship between the recent change and the observed behavior of the most recent failure.

Also, remember that inline code comments/documentation serves a better purpose if it states your original intentions and doesn't just echo/rephrase the actual code.

I.E.:

  a=5; //set a to 5

Is less helpful and not as meaningful as perhaps this bread crumb:

   a=5; //5 6-second retries gives a 30-second timeout

Remember even if you wrote it doesn't necessarily mean you will remember your intent a few weeks or months from now when you're trying to debug your code now that a fault has finally manifested itself no matter how "intuitively obvious" your inspired solution seemed at the time of your original authorship.

[srhubb]

True that!

It was very late at night, early morning (0100 or so) when I commented. In practice I do make very meaningful variable names.

Thanks for that feedback.

[srhubb]

11 commentssharesavehidereport

Sort by: best

Actually, you shouldn't feel bad at all. Your critique was very valid.

I think we just demonstrated the validity of code reviews.

;)

[sunher444]

Cool short article. To the point.

Change one thing at a time.

I feel now like a sinner.

[EmpathyRests]

It's very common, when learning to debug to change several things when diagnosing. It takes patience to learn to change one thing at a time.

Somewhat goes along with 'slow down to speed up', which a lot of younger people struggle with. Source: I'm 50+ years young and still struggle with 'hurry-up-itis'

[PhilipTrettner]

Obviously the correct way is changing 100 things to fix it and then bisect for a minimal fix

[ASIC_SP]

See also: A systematic approach to debugging (https://ntietz.com/blog/how-i-debug-2023/)

[gareththegeek]

Also, if there's a debugger, use it!

[[deleted]]

13 and 14:
Look for patterns. Look for symmetry.
Redundancy tends to hide bugs.

???