alt Hacker News> 1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.
Maybe? Although it seems more like it's actually #5:
> 5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.
where in my imagined scenario, a student that just finished the lab successfully could pull out their DIP-8 device and swap in the author's to validate that it was possible to make it work in a known good environment.
Odd. When I look at it, the first item is my own suggestion for debugging:
> In my experience, the most pernicious temptation is to take the buggy, non-working code you have now and to try to modify it with "fixes" until the code works. In my experience, you often cannot get broken code to become working code because there are too many possible changes to make. In my view, it is much easier to break working code than it is to fix broken code.