Comment by anyfoo

Comment by anyfoo 3 days ago

No offense, but... when I was reading your story, I was somehow at least assuming that the marking on the part was somewhat unreadable or something...

After getting befuddling answers, would it not have been natural to check the base assumptions, starting with do I have the correct part? That is true as much in the "real engineering" world, as in school.

You say "It could _never_ be the equipment's fault" as if it was, but it wasn't. The test equipment gave you correct answers, your device under test was wrong.

Bjartr 2 days ago

I'd say it's not natural to check for the correct part that has been given to you by an authority that claims to have done so, but a learned problem solving technique.

Reply View 0 replies

opello 3 days ago

Or even more likely in a lab setting: have another student test your part in their setup for A/B validation testing.

Reply View 2 replies

hughdbrown 3 days ago

Sort of like the first debugging tip here:
https://news.ycombinator.com/item?id=42682602

Reply View | 1 reply
- opello 3 days ago
  
  > 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.
  
  Reply View | 0 replies