←back to thread

903 points tux3 | 10 comments | | HN request time: 0.883s | source | bottom
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(46): >>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 #>>43676296 #
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 #
1. Natsu ◴[] No.43549249[source]
It's funny, because while that's a terrible educational experience, you actually learned some important lessons despite them.

I remember the first time I found out that the software documentation I had been relying upon was simply and utterly wrong. It was so freeing to start looking at how things actually behaved instead of believing the utterly false documentation because the world finally made sense again.

replies(3): >>43549498 #>>43549523 #>>43549811 #
2. euroderf ◴[] No.43549498[source]
Proving the truism that incorrect documentation is worse than no documentation.
3. don-code ◴[] No.43549523[source]
Sometimes it's not even rare that documentation is wrong. The documentation for a vendor who I won't name - but might be at Series J and worth north or $50 billion - seems to be wrong more often than it's right.

We frequently say, don't blame the tools, it's you. That pushes "blame the tools" outside of the Overton window, and when we need to blame a tool, we're looked at like we have five heads.

Ten years ago, I was dealing with a bizarre problem in RHEL where we'd stand up an EC2 instance with 4GB of memory, have 4.4GB of memory reported to the system, and be able to use 3.6GB of it. I spent _a long_ time trying to figure out what was going on. (This was around the time we started using Node.js at that company, and needed 4GB of RAM just for Jenkins to run Webpack, and we couldn't justify the expensive of 8GB nodes.)

I did a deep dive into how the BIOS advertises memory to the system, how Linux maps it, and so forth, before finally filing a bug with Red Hat. 36 hours later, they identified a commit in the upstream kernel, which they forgot to cherry-pick into the RHEL kernel.

That's a very human mistake, and not one I dreamed the humans at Red Hat - the ones far smarter than me, making far more money than me - could ever make! Yet here we were, and I'd wasted a bunch of time convinced that a support ticket was not the right way to go.

replies(2): >>43549918 #>>43549962 #
4. mandevil ◴[] No.43549811[source]
I took and then TA'd a class where the semester long project was to control robots (it was a software engineering principles class, the actual code writing could be done in a single weekend, but you had to do all the other stuff of software engineering- requirements analysis and documentation etc).

We had a software simulator of the robots, and the first lab was everyone dutifully writing the code that worked great on the simulator, and only then did we unlock the real robots and give you 2-3 minutes with the real robot. And the robot never moved that first lab, because the simulator had a bug, and didn't actually behave like the real robot did. We didn't deliberately design the robot that way, it came like that, but in a decade of doing the class we never once tried to fix the simulator because that was an incredibly important lesson we wanted to teach the students: documentation lies. Simulators aren't quite right. Trust no one, not even your mentor/TA/Professor.

We did not actually grade anyone on their robot failing to move, no grade was given on that first lab experience because everyone failed to move the robot. But they still learned the lesson.

replies(2): >>43550079 #>>43550813 #
5. Eduard ◴[] No.43549918[source]
> Yet here we were, and I'd wasted a bunch of time convinced that a support ticket was not the right way to go.

From my experiences with public issue trackers for big projects, it's very reasonable to postpone creating a new issue, and rather follow my own hypothesis/solution first:

* creating a new issue takes significant effort to be concise, provide examples, add annotated screenshots, follow the reporting template, etc., in hopes of convincing the project members that the issue is worth their time.

Failing to do so often results in project members not understanding or misunderstanding the problem, and all too often leads to them directly closing the issue.

And even when reporting a well-written issue, it can still just be ignored/stall, and be autoclosed by GitHubBot.

6. Natsu ◴[] No.43549962[source]
In my case, it was egregiously bad, because someone had cribbed docs from an entirely separate scripting language that did almost the same things. Most of the same features were there, but the docs were utter lies, and failures were silent. So you'd go down the wrong branch of an if statement because it wasn't checking the conditions it claimed to check.

Once I started actually testing the scripts against the docs and rewriting them, life got so much better. The worst part is that it had been that way for years and somehow nobody noticed because the people using that horrible scripting language mostly weren't programmers and they'd just tweak things until they could happy path just enough to kinda-sorta work.

7. don-code ◴[] No.43550079[source]
Just out of curiosity, were you up-front after the fact that this was part of the exercise?

We had a first-semester freshman year course that all incoming students were required to take. The first assignment in that class was an essay, pretty typical stuff, I don't even remember what about.

A day after handing it in, roughly half of the class would be given a formal academic citation for plagiarism. That half of the class hadn't cited their sources. "This one time only", the citation could be removed if the students re-submitted an essay with a bibliography.

While it was obvious, in hindsight, that the point of the exercise was to get you to understand that the university took plagiarism seriously, especially with the "this one time only" string attached, it felt dishonest in that nobody ever came out and said so. I luckily wasn't on the receiving end of one of those citations, but I can only imagine the panic of a typical first-semester freshman being formally accused of plagiarism.

replies(2): >>43550270 #>>43554702 #
8. mandevil ◴[] No.43550270{3}[source]
If someone complained to us TAs during or after the lab that the simulators were incorrect, we were quite open that indeed they were, and that was not our doing, but we were okay with it because lying documentation was a part of the real world.

The professor had been doing the class with those robots for several years when I took the class the first time, but I don't know if he acquired that brand of robots because their simulator was broken or if that was just a happy accident that he took advantage of.

The lesson certainly has stuck with me- this was one lab in a class I took almost a quarter-century ago and I vividly remember both the frustration of not moving the robot and the frustration of everyone in the sections that I TA'd.

9. hermitdev ◴[] No.43550813[source]
> because the simulator had a bug

I had something similar happen when I was taking microcomputers (a HW/SW codesign class at my school). We had hand-built (as in everything was wire wrapped) 68k computers we were using and could only download our code over a 1200-baud serial line. Needless to say, it was slow as hell, even for the day (early 2000s). So, we used a 68k emulator to do most of our development work and testing.

Late one night (it was seriously like 1 or 2 am), our prof happened by the lab as we were working and asked to see how it was going. I was project lead and had been keeping him apprised and was confident we were almost complete. After waiting the 20 minutes to download our code (it was seriously only a couple dozen kb of code), it immediately failed, yet we could show it worked on the simulator. We single-stepped through the code (the only "debugger" we had available was a toggle switch for the clock and an LED hex readout of the 16-bit data bus). I had spent enough time staring at the bus over the course of the semester that I'd gotten quite good at decoding the instructions in my head. I immediately saw that we were doing a word-compare (16-bit) instead of a long-compare (32-bit) on an address. The simulator treated all address compares are 32-bit, regardless of the actual instruction. The real hardware, of course, did not. It was a simple fix. Literally one-bit. Did it in-memory on the computer instead of going through the 20-minute download again. Everything magically worked. Professor was impressed, too.

10. varjag ◴[] No.43554702{3}[source]
Right. I'm all for making freshmen learn it early but this is just hazing.