Systematic Troubleshooting Methodology

Randomly changing code and re-testing — sometimes called "shotgun debugging" — often masks the real cause, wastes time, or introduces an entirely new bug on top of the original one. A structured approach converges on the actual root cause reliably, rather than by luck.

1. Reproduce reliably. A bug that can't be triggered consistently can't be verified as fixed either.
2. Isolate the layer. Is this a client-side JavaScript problem (Lesson 1), an Apex/wire boundary issue (Lesson 3), or purely server-side Apex logic (Lesson 2)? Each layer has different tools.
3. Read the actual error precisely. Skimming an error message and guessing at its meaning is a common, avoidable source of wasted time — read it fully, including the stack trace.
4. Form a specific hypothesis. "Something's wrong with the wire" is too vague; "the reactive parameter isn't populated because of a typo in the property name" is testable.
5. Test the hypothesis with the smallest possible change. A large, sweeping change makes it unclear which part actually fixed (or didn't fix) the problem.
6. Verify the fix, and check for regressions. Confirm the original bug is genuinely gone, and that nothing else broke as a side effect.

A report says: "the save button doesn't work." Following the method: (1) reproduce it — click the button, confirm nothing happens; (2) isolate — check the Console for a JavaScript error first, since that's the most common client-side symptom; (3) read precisely — the error says Cannot read property 'value' of undefined at a specific line; (4) hypothesize — a queried element wasn't found, likely because of a typo in a selector; (5) test minimally — fix just that selector, nothing else; (6) verify — click the button again, confirm it now works, and re-run the existing tests to check nothing else broke.