Home/ Questions/Q 58049
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T17:47:13+00:00

There are many skills a programmer could have (understanding the problem, asking good questions,

  • 0

There are many skills a programmer could have (understanding the problem, asking good questions, good design skills, etc.).

I think System Debugging skill is incredibly valuable. This general skill of debuggin any technical system (from the batteries being dead in your remote control to signal interference from your neighbor’s Ham Radio).

Here’s the method I gave students when I taught Computer Programming:

  1. Define the Problem (when I perform XYZ Repro Steps, I get ABC Symptom)
  2. Identify the Testing Scope and break into sections.
  3. Test each section using process of elimination to find the section causing the problem.
  4. Break section down into subsections if needed.
  5. Analyze the subsection causing the problem.
  6. Fix.
  7. Text by using Steps to Reproduce the Symptom.

Whadaya think?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. if you define ‘troubleshooting’ to include ‘debugging’ then yes, it is critical!

    EDIT: based on your edits, the top-down process-of-elimination technique you listed is systematic and very valuable.

    Another technique is reasoning backwards:

    • start at the end, with the variables/calls that produce the symptom/bug
    • reason backwards from there – what could have caused this incorrect value or bad call?
    • continue to trace backwards in the logic until you find the culprit

    This is useful when there are a lot of forward-feeding paths/possibilities that could have caused the problem, but has the advantage of not needing a debugger or tracing to figure out the most likely cause.

    Another technique is the usual-suspects technique, where you begin your investigation with whatever part of the code was touched last or has given you the most problems, to see if something changed in it to cause the new issue

    Another technique is to just sit and think about what situations could possibly produce the bug/behavior/value observed. This technique is useful when you’re in a hurry and don’t want to systematically scan a lot of places, but requires that you already have a thorough understanding of the system. This is useful when the bug/behavior in question is due to a design flaw or oversight and not a coding error.

    • 0