Someone else's program, line down: read it cold

You'll rarely troubleshoot code you wrote. The skill is walking into an unfamiliar program under pressure and reverse-engineering the designer's intent fast — from the output back, through routines and comments, to the fault.

A faultline101 training module · the skill behind six hands-on scenarios

You'll rarely troubleshoot code you wrote. Walk into a strange program, trace one dead output backward, and reverse-engineer the designer's intent — fast, under pressure.

The idea

Real troubleshooting almost always happens in someone else's program, often with the line down and a crowd waiting. You don't need to understand the whole thing — you need to follow one dead output back to its cause without getting lost.

The moves that keep you oriented: start at the output that won't come on and cross-reference backward; follow subroutine calls (JSR) into the routines where the real logic lives; lean on tag names and rung comments to grasp intent; and respect scan order, because a bit set in a later routine can affect one read earlier.

One warning: comments and tag names are documentation, and documentation lies. A copy-pasted rung can carry a comment describing what it used to do. When the live logic and the comment disagree, believe the logic — it's what's actually running.

Six faults you'll work in this module

You don't learn this by reading it — you learn it by doing it on six different faults, each drilling the same skill until it's instinct:

1. Start at the output, not page one. Symptom to cause without ever knowing the machine.
2. Follow the call. You didn't get lost — you followed the structure into the routine.
3. Let the names talk. Good tag names and comments handed you intent in seconds.
4. Order of operations. Understanding scan order untangled what looked contradictory.
5. The comment that lies. When the comment and the live logic disagree, believe the logic.
6. Cold, under pressure, fix it. Strange machine, no help — solved by method, not memory.

The mistakes it kills

• Trying to read the whole program instead of tracing one output backward
• Assuming all the logic is in the main routine and missing the subroutine where it lives
• Trusting a rung comment or tag name over what the live logic is actually doing

Why it matters: Being able to read a strange program cold is what lets you fix a machine you've never seen, in a plant you just walked into, without waiting for the OEM.

More: Follow the rung backward · Get the comic · All troubleshooting guides.