Hacker News Reader

Comment by don-code | Hacker News Reader

It's a good question! I didn't think to check the markings on the chip. The lab tech was convinced I was doing something wrong with my setup, and likewise he had me convinced it must be something wrong with my setup.

Coincidentally, I've been knee-deep in some problems that I've applied the Cynefin framework to. I'd call this problem "chaotic", where throwing things at the wall might be _more_ effective than working down a suggested or tried-and-true path from an expert. I was pleasantly surprised just a few weeks ago where one of the more junior engineers on my team suggested updating a library - something I hadn't considered at all - to fix an issue we were having. (That library has no changelog; it's proprietary / closed source with no public bug tracker.) Surely enough, they were right, and the problem went away immediately - but I was convinced this was a problem with the data (it was a sporadic type error), not a library problem.

View on HN

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.

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

Sort of like the first debugging tip here:

https://news.ycombinator.com/item?id=42682602

> 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.

I think we may have just had different interpretations of "here" in this instance. I took it to mean the article at the link, while you meant the comment that you authored?

I will justify my interpretation because saying "first" primed me to expect a list and the linked comment (and portion quoted) only suggests rewriting, while the article at the link mentions 9 rules to keep in mind during debugging.

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 on news.ycombinator.com