←back to thread

896 points tux3 | 1 comments | | HN request time: 0.201s | source
Show context
jerf ◴[] No.43546861[source]
One of my Core Memories when it comes to science, science education, and education in general was in my high school physics class, where we had to do an experiment to determine the gravitational acceleration of Earth. This was done via the following mechanism: Roll a ball off of a standard classroom table. Use a 1990s wristwatch's stopwatch mechanism to start the clock when the ball rolls of the table. Stop the stopwatch when the ball hits the floor.

Anyone who has ever had a wristwatch of similar tech should know how hard it is to get anything like precision out of those things. It's a millimeter sized button with a millimeter depth of press and could easily need half a second of jabbing at it to get it to trigger. It's for measuring your mile times in minutes, not fractions of a second fall times.

Naturally, our data was total, utter crap. Any sensible analysis would have error bars that, if you treat the problem linearly, would have put 0 and negative numbers within our error bars. I dutifully crunched the numbers and determined that the gravitational constant was something like 6.8m/s^2 and turned it in.

Naturally, I got a failing grade, because that's not particularly close, and no matter how many times you are solemnly assured otherwise, you are never graded on whether you did your best and honestly report what you observe. From grade school on, you are graded on whether or not the grading authority likes the results you got. You might hope that there comes some point in your career where that stops being the case, but as near as I can tell, it literally never does. Right on up to professorships, this is how science really works.

The lesson is taught early and often. It often sort of baffles me when other people are baffled at how often this happens in science, because it more-or-less always happens. Science proceeds despite this, not because of it.

(But jerf, my teacher... Yes, you had a wonderful teacher who didn't only give you an A for the equivalent but called you out in class for your honesty and I dunno, flunked everyone who claimed they got the supposed "correct" answer to three significant digits because that was impossible. There are a few shining lights in the field and I would never dream of denying that. Now tell me how that idealism worked for you going forward the next several years.)

replies(45): >>43546960 #>>43547056 #>>43547079 #>>43547302 #>>43547336 #>>43547355 #>>43547446 #>>43547723 #>>43547735 #>>43547819 #>>43547923 #>>43548145 #>>43548274 #>>43548463 #>>43548511 #>>43548631 #>>43548831 #>>43549160 #>>43549199 #>>43549233 #>>43549287 #>>43549330 #>>43549336 #>>43549418 #>>43549581 #>>43549631 #>>43549681 #>>43549726 #>>43549824 #>>43550069 #>>43550308 #>>43550776 #>>43550923 #>>43551016 #>>43551519 #>>43552066 #>>43552407 #>>43552473 #>>43552498 #>>43553305 #>>43554349 #>>43554595 #>>43555018 #>>43555061 #>>43555827 #
don-code ◴[] No.43548274[source]
This is, more or less, exactly what happened when I took Electronics I in college.

The course was structured in such a way that you could not move on to the next lab assignment until you completed the one before it. You could complete the lab assignments at your own pace. If you failed the lab, you failed the class, regardless of your grade.

The second or third lab had us characterize the response of a transistor in a DIP-8 package, which was provided to us. If you blew it up, you got a slap on the wrist. That DIP-8 was otherwise yours for the class.

I could _never_ get anything resembling linear output out of my transistor. The lab tech was unhelpful, insisting that it must be something with how I had it wired, encouraging me to re-draw my schematic, check my wires, and so on. It could _never_ be the equipment's fault.

Eight (!) weeks into that ten week class, I found the problem: the DIP was not, in fact, just a transistor. It was a 555 timer that had somehow been mixed in with the transistors.

I went and showed the lab technician. He gave me another one. At this point, I had two weeks to complete eight weeks of lab work, which was borderline impossible. So I made an appointment to see the professor, and his suggestion to me was to drop the class and take it again. Which, of course, would've affected my graduation date.

I chose to take a horrible but passing grade in the lab, finished the class with a C- (which was unusual for me), and went on to pretend that the whole thing never happened.

replies(17): >>43548368 #>>43548469 #>>43548484 #>>43548871 #>>43549249 #>>43549256 #>>43549629 #>>43549683 #>>43550176 #>>43550399 #>>43551048 #>>43551251 #>>43551551 #>>43553532 #>>43554766 #>>43554936 #>>43556056 #
orlp ◴[] No.43548484[source]
What I don't understand is why it took you 8 weeks to distinguish a timer from a transistor. That doesn't make your professor's reaction alright, I just find it puzzling.
replies(7): >>43548759 #>>43548763 #>>43548830 #>>43548967 #>>43549241 #>>43552038 #>>43553256 #
don-code ◴[] No.43548830[source]
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.

replies(1): >>43552541 #
anyfoo ◴[] No.43552541[source]
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.

replies(2): >>43553122 #>>43558231 #
opello ◴[] No.43553122[source]
Or even more likely in a lab setting: have another student test your part in their setup for A/B validation testing.
replies(1): >>43553390 #
hughdbrown ◴[] No.43553390[source]
Sort of like the first debugging tip here:

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

replies(1): >>43553447 #
1. opello ◴[] No.43553447[source]
> 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.