Comment by don-code

That's fair, but in this case it should be pretty easy to verify if the person is lying. The claim is highly reproducible and the instructor wouldn't even have to do it.

Note that AI provides a whole new range of possibilities for automating lying about assignments.

Unfairness to the class, if kept under wraps, is a case of no one actually being harmed.

Option 3: treat your students like adults as much as possible and be flexible with everyone about how they complete the class as long as they demonstrate that they've done sufficient work and have sufficient mastery of the material. Then you don't need to play arbiter about whether having a child in the hospital is a better excuse than having their backpack stolen, and you don't unfairly favor squeaky wheels over meeker students.

I forgot where I read that large organisations are effectively accountability dilution machines. No one is fully in charge, and everyone gets to say that their hands are tied, that computer says no.

This is the dark side of scale.

It bugs me that oftentimes there appear to be nothing but cogs (e.g. Intel)

I hear so many horror stories in the sciences, I have no idea why anyone would pursue an academic career in it.

That's why you should select your PhD advisor very carefully.

Yeah that sucks, the hard life lesson where you have to swallow your pride and go "fine, I will put quotes on the infernal thing"

But... it does not print a string, a string goes into it but what comes out of the function is not that programmatic feature we call a string in any way shape or form, what comes out depends on the output device specified, it may be ink on paper, lit phosphors, or a stream of bytes. none of which can you use in your program as a string.

sprintf being a notable exception of course. there you do get a string out of it.

Update: language is weird and the more I read my statement the weirder it gets, all I can do is add this cryptic note. "When you print a string it does not produce a string", this usually means I am wrong about something.

Depending on your environment, the above printf might print nothing at all, because there is no trailing newline.

I have my own, similar stories but, as a mediocre student, they were lost in the noise of my own mistakes. Nonetheless it's injustice, so I still remember it. Some people on this site were really excellent students, where these deductions really mattered. I don't know how they cope.

The kind of prof who never coded a useful program in his life.

A kid might see it in terms of "authority figures," but live long enough and you'll understand it's everyone. Not just your professors and bosses, but your subordinates, your friends, your lovers, even your children will judge you unjustly from time to time. But that doesn't mean the world is poison and existence is a curse. It just means you have to learn to get by despite other people's imperfections the same way they get by despite yours.

That sometimes you can do everything right and still lose.

Message for engineering undergraduates: when you have an opportunity to trade great grades for good grades and increased immediate career prospects, take it.

Your internship / prospective employer cares way more about the job you're doing for them than +0.5 GPA.

(If you're heading right to grad school, obviously different weighting)

Yeah, I'm not going to say that undergrad doesn't matter, but your grades are not exactly an indication of whether or not you're getting useful life and professional skills out of it. I was a straight-A high school student, but finished university a semester late with a 2.975 GPA. I've since had a wildly successful career in software development (my degree is in electrical engineering), and my college years toiling about in labs are but a dim memory.

Certainly the name of the school on my resume helped me interview for my first job, and I did learn a bunch about how computers worked and how to design CPUs, and that was useful early in my career when I worked on embedded software (like actually embedded, weak-ass MIPS machines with a handful of MB of RAM, and no MMU or memory protection[0]; not the tiny supercomputers that count as "embedded" these days). But my grades, and most of the getting-my-coursework-done drama? Irrelevant.

[0] And I'm sure some folks here will consider what I had to work with a luxury.

I probably learned more in my first year of working than I did in my degree. Not just technical skills and gaps that had been glossed over during study, but also about myself as an individual. You made the right choice, and it's one I wish I had the foresight and maturity to have made at that point in my life.

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.

It's closer to exposing a first year CS student who has never touched a computer before to Windows, when the work is supposed to be done on Linux, and the TA is hemming and hawing, and insists that the reason the sudo command isn't working is because the student is not following the steps correctly.

It's a problem that's obvious to diagnose... If you already have passing familiarity with the material. Most people do not have passing familiarity with electronic components when they step into an engineering program.

The part was marked as a timer IC.

ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them!

Trust, but verify.

But that's the thing that both students and often the teachers forget. We don't run labs to go smoothly, we run labs because you'll have to troubleshoot. There is no learning experience in a lab that works without issues, in fact IMO if lab instructions are of the step by step type, they should always have some deliberate errors in it to get students to troubleshoot.

To play devil's advocate, just imagine the previous posters Story at a company, i.e. a junior engineer not being able to make some simple tasks work and telling their supervisor "it doesn't work" and it turns out after 8 weeks they grabbed some wrong part. Should they have expected their supervisor to check all the parts? Should they expect a good performance evaluation?

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

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.

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

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.

Never seen any DIP-8 transistors. Usually the discrete arrays like the CA30xx are DIP-14. Personally I'd read the label on the chip.

ULN2003 is not DIP8

And I would assume for pedalogical purposes a bare transistor would be preferred rather than the '2008 with its extra diodes and base resistor.