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.
That is enraging. I've seen similar things happen too and it blows my mind how ridiculous some of these teachers can be. I don't know if it's dehumanization of their students in their minds or an utter unwillingness to devote 30 seconds of directed attention to understanding the situation and making a reasonable judgment, but whatever the cause it is prolific. The only thing worse is when one of them will add something like, "life isn't fair, get over it" when it's fully in their power to make a reasonable determination.
The flip side of this is from the professor's perspective: some undergrad in every class will lie their ass off about why their assignment was delayed.
Unfortunately, this reality produces no good options if you think someone is telling the truth: (1) make an exception, and be unfair to the rest of the class or (2) don't make an exception, and perpetuate unfairness for the impacted student.
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.
It's only "reproducible" if you find other 555's mixed in the shipment but not distributed to students. Depending on what the error rate in the shipment packing is, that might be very easy or it might be quite hard. At any rate, it's a stats problem that the professor is unlikely to want to engage with. Unfortunately.
For the next semester, a good prof would have a QA step or a harnass that turns on a green light if you plug in a working-as-expected package. I can see how the lab assistant job gets plenty to do in a well-run course, and also how unlikely it is to be happening in real life. There aren't enough incentives.
I suppose, although if the student is able to show the prof with the tools that the chip they have (which based on the story should be visually identical or very similar to the rest of the chips) behaves incorrectly, that test can be repeated many times. It's possible the student could have acquired it elsewhere and is snowing, but even if that's the case the fact that they can do the analysis and show (and waited so long in the class to get there), and have the history of asking for help throughout the course, all add up to pretty powerful evidence IMHO. The prof could even do his own test with the chip if he doubts. It seems hard to believe that one student would intentionally try to "cheat" by making his life much, much harder. It's surely a path of much less resistance to just follow the book.
How? What happens when students start buying faulty hardware to justify unrelated delays?
Yes, although just having the faulty hardware isn't enough. They also have to use the tools to show that it behaves incorrectly, which is surely a lot more work than just following the book would have been. That is the part that is easily reproducible. The student already knows how, so in a few minutes he can set it up in front of the prof and show him. The prof needn't do anything other than watch for a few mins.
If more of these cases crop up then you should get suspicious, but you also need to consider the impact of giving a student the wrong chip and expecting them to succeed! I think Blackstone's Ratio should apply here personally
As a teacher, my first rule is, be kind. Sure, there are people who will take advantage of the situation, but they are not really taking advantage of me.
In this case, I'd have a harness that ensures the parts they were given work as advertised, and make it the students' responsibility to report within the first 3 days if it is not working.
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.
The problem: it won't stay under the wraps. People talk. Feels shitty when the scammer tells everybody how easy scamming was, when you yourself worked through the night to finish your assignment.
Translation: scammers get the green light.
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.
It's a general problem with large bureaucracies. If you're a cog in the machine, the safest way is to always stick to the rules, and avoid any situation where one has to exercise discretion, since any personal judgment comes with potential personal responsibility down the line.
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.
THe original version of that idea seems to come from "The Unaccountability Machine: Why Big Systems Make Terrible Decisions - and How The World Lost Its Mind", by Dan Davies (the "Lying for Money" guy.)
There's a shorter interview with him (in podcast form, includes a well-made transcript) going into these ideas at https://www.complexsystemspodcast.com/episodes/dan-davies-or...
It bugs me that oftentimes there appear to be nothing but cogs (e.g. Intel)
Aggression, Social Stress, and the Immune System – Takahashi, Flanigan, McEwen & Russo, 2018
https://www.frontiersin.org/journals/behavioral-neuroscience...
“Aggression has an adaptive significance for most animal species and is critical for acquiring and protecting territory, food, reproductive mates, and offspring. In animals with hierarchical societies, aggressive behavior is thought to help individuals gain and maintain higher social status (Box 2). It has been shown that aggressive behavior, especially the experience of winning, has rewarding properties in animals and repeated aggressive experience may lead to compulsive, pathological aggression that is highly reinforcing (Fish et al., 2002; Falkner et al., 2016; Golden et al., 2016, 2017).”
Just wait until that teacher is your graduate advisor.
I hear so many horror stories in the sciences, I have no idea why anyone would pursue an academic career in it.
Well in the industry you have the weekly JIRA humiliation rituals, bad things are everywhere
What's this a reference to? Not familiar with JIRA humiliation rituals.
Scrum/Kanban ceremonies with assigning points to tasks etc. GP is being melodramatic
I've been redditing for 15 years and until a week ago here on HN, I've never seen the previous commenter reffered to as GP. What is that an acronym for?
GrandParent
Parent is the comment you're replying to, GrandParent is the comment above that, OP is the original poster.
At this point it’s the track to get a visa to work and live in the US. I’ve met so many graduate researchers who put up with way more bullshit than I would ever deal with. And why most grad programs are mostly immigrants.
I only took two electronics classes, but in the later one I was the class hero for just buying a bunch of potentiometers on amazon so that we didn't have to waste all of that expensive time sitting around waiting for our turn with the only good one left. It cost me like $10
I was in honors freshman chemistry at university. Tough class, all homework (lots of it) graded rigorously, but only the midterm and final counted toward the course grade. So if you wanted an A you had to get an A on both exams.
After midterm, during every other lecture at least, the professor would sound a refrain: “An orbital is not a house! An electron does not live in a house!”
Final exam had a small number of complex problems to work out with pen and paper, tough stuff, lots of calculus. But the last question ended with “where does the electron live?”
That final problem, if you ignored the end wording, was super easy, something almost trivial to do with Helium iirc. The class had about 25 students in it; about 5 of us independently had the same thought: “this is a trick question, ‘the orbital is not a house in which the electron lives!’” And, independently, that’s how we five answered.
And we got marked wrong, all our course grades dropped to B+/- because of that one damn question.
Over a lunch or whatever, we discovered our shared experience and approached the professor as a group. He listened patiently and said: “Ah, right, I did insist on that idea, it’s understandable why you would think it’s a trick question and answer that way. But I still consider your answers wrong, grades stay as they are.” Some in the group even went to the dean and, to my understanding, he said it’s best to consider it a life lesson and move on.
Having gone both to a liberal arts institution and a large public university, it is not clear to me what the professors in the latter were actually doing vis a vis their teaching responsibilities that actually provided value.
Lectures that came straight from the book I could have read, recitations and problem reviews done by grad students, and tests that were little more than variations on homework problems of varying difficulty.
Maybe they were getting paid for research, but I dunno. At the liberal arts college, I actually received an education instead of bootstrapping it myself from a syllabus.
I agree this seems overly principled to me.
I recall a DSP class where there was an exam with a question like (not exactly this):
> What does the following code print?
> `printf("Hello, world!");`
If you responded with:
> Hello, world!
...which - of course - the whole class did, you got the question wrong.
If you responded with:
> "Hello, world!"
...which is actually not what that would print, you got the question right.
A small band of us went to the professor and noted that, in fact, `printf("Hello, world!")` does not print the quotes. But he wanted us to show that it printed a string, and we denote strings by quotes.
This was something that we learned to do just for him - all strings had to be enclosed by quotes, to denote that they were strings. As far as I'm concerned, it served no practical purpose; we never had to differentiate strings like "Hello" from ['H', 'e', 'l', 'l', 'o', 0] or other representations.
A better example of how this could go - and not one that had anywhere near the same stakes - was a question on the entrance exam for my college radio station:
> What is the airspeed velocity of an unladen swallow?
I got this question right by answering, "Ni!"
(edit: formatting)
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.
"string" is a type that only makes sense inside the context of a specific programming language, because programming languages differ on what a string is and how it behaves (is it guaranteed to be valid UTF8, does it carry its own length around with it, is it runes/graphemes and can't be split on byte boundaries easily, is it mutable, etc).
Double quotes are a syntax sugar for string literals in source code, in a particular language, to avoid writing `string.from_byte_array([97, 98, 99])` or `new String({97, 98, 99});` or whatever. Strings are single quoted not double quoted in Dyalog APL, there's several different strings in SWI Prolog depending on using double quotes or backticks and how the flags are set.
stdout is an untyped byte stream which could go to a printer or Braille terminal or anything as you say, but could be terminal control codes, image data, or whatever. The OS doesn't tend to have a 'string type' ... but in PowerShell `write-output "a"` will write a .NET System.String to the output stream, but it won't use "printf()".
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.
Yeah? What "life lesson" does the dean think you're going to learn from that? That authority figures cannot be trusted because they will hurt you with bureaucratic stupidity. Does the dean, as an authority figure, really want that to be the lesson you learn?
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.
>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.
This sentence could have also ended "my gpa dipped below the threshold for some bullshit mark it up to mark it down exercise masquerading as a scholarship and I had to re-take the class for a better grade anyway"
Indeed it could have. I was on a fairly prestigious scholarship; luckily, my marks were good enough that this was a low-risk decision.
That said...
I graduated with a 3.2 GPA, after being the stereotypical "gifted" student up through high school. A 3.2 is, apparently, still decent. However, I did feel a bit of a twinge seeing my peers walk at graduation with with cords, bents, and other regalia, where I just had my standard-issue black robe.
It had less to do with my grade in this particular class, and more to do with the fact that I had a part-time engineering job - 10-20 hours a week - and was making money. When you've spent a couple of years being broke, having an extra few hundred dollars per month was a big deal. Enough so that I didn't really care about putting the extra effort in for A's - that extra time was time better spent working. B's were fine if I could afford to take my girlfriend out to dinner every month.
In the years since then, it seems like this was a good decision. That job became full-time after college, and I stayed there six years. At the end of six years, nobody really cared about my college GPA. At the end of nine years (when I next looked for a job), I didn't even bother listing it on my resume.
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)
If you're heading to grad school, it can be essential to have connections made through UG research. That's a trade that isn't just advised in some fields, but necessary. A letter of recommendation that says you're actually useful as an RA is 1000x more of a direct implication that they would benefit from bringing you on than an A in a few classes. Academics don't like finding out that smart people are impossible to work with any more than industry does, and since they're tied to you for longer, in some ways it's an even bigger deal.
You'll have a hard time getting an internship if you don't meet an arbitrary GPA cutoff.
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.
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.
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.
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.
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.
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:
> 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.
That would be like exposing a first year CS student to a situation where "it could be a compiler bug" is one of the potential explanations.
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.
Not just a timer IC. Literally the most common IC in the world for at least every year from 01980 to 02000 or so, maybe still today. I can understand the first-year student not recognizing it, but what the fuck was the lab tech's mental disability?
I would assume that you don't have access to the lab(and diagnostic equipment) at all times and taking other classes.
Also him being a student, having the wrong component was probably not in his mental troubleshooting tree. I would guess that it was not in the lab assistant's troubleshooting tree either.
Also once you start down the road of troubleshooting, a false trail can lead you far into the woods.
Same package. 555 is typically a DIP-8, transistor packages are available in the same. So you would have to examine the cryptic markings and compare them with the other students, and that’s only if you suspected some fuckup on the part of the knowledgeable people.
ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them!
Trust, but verify.
Yes, my strict adherence to “trust but verify” was born from literal tears. It’s not worth trusting others if it takes a small fraction of the projects time to verify. It has saved me incredible amounts of time in my professional life, and I’ve seen months wasted, and projects delayed, by others who hadn’t cried enough yet.
I would love to hear some of your examples, if only to reinforce your lesson to myself.
“Is the box plugged in? Did you cycle the power?”
I’ll trust that you understand each of those words individually but later verify that the box is actually plugged in.
That's why tech support has moved on to "unplug the thing, wait a minute, then plug it back in".
It gives the capacitors to discharge; but more importantly, it gives an excuse to actually force the person to plug the thing in.
I ask people to unplug their Ethernet cable and tell me the colors they see on the wires all the time.
I don't care, of course. But they'll happily do that, where if I ask them to verify if the cable is properly plugged in, 99% of them will just say yes without so much as glancing in the cables' direction.
Earlier in my career the clients system was not powered at all, I did:
"Is it plugged in and switched on?" A: Yes, to a powerboard.
"Is the powerboard plugged in and switched on?" A: Yes.
I did the onsite visit and found the powerboard plugged into itself.
Normally I would facepalm and curse the idiocy but... it was a care respite facility and they had more pressing issues to deal with that I wouldn't want to deal with - their role is heroic I feel.
And an easy win already makes my day so I sorted it, told them it was fixed with a smile, and continued on.
"Trust, but verify" is just a polite (ie corporate) way of saying "Don't trust until you verify", right?
No, it says that projects should move forward without verifying that prerequisites have been fulfilled, but that the verification should take place anyway. It's about the pace at which you can go.
Trust-free:
Ensure that step A can go off without a hitch.
Begin step A.
Ensure that step B can go off without a hitch.
Begin step B.
Ensure that step C can go off without a hitch.
Begin step C.
Begin step A.
Begin step B. Check that you have whatever you need for step A.
Begin step C. Check that you have whatever you need for step B.
Check that you have whatever you need for step C.
I can only make sense of that saying in terms of how much trust to give, whether it's a high-trust or low-trust environment. Whether you assume good-will and basic competence or not.
e.g. you might assume that a sorting library from an internal developer at your company will put things in order but you might want to verify that it has reasonable worst-case performance for your use case. A no-trust situation might lead you to scrutinise everything about it - does it work at all, does it have horrendous performance in every case, is it a supply-chain attack with disguised errors leading to deliberate exploit holes.
In this case, "trust but verify" might mean assuming the Professor and TA are doing an experiment they have done before, which basically works, but might have made a mistake or missed something while setting it up, writing the slides, or explaining it to you. "Don't trust" might mean the TA got the experiment from ChatGPT, hates OP for being on a scholarship and is trying to sabotage their success, and the whole thing isn't an Electronics course it's really the Professor's practical joke/psychology experiment about stressing students.
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?
If after eight weeks a junior engineer is still toiling on their story, I'd ask why someone more senior didn't get involved.
There are lots of reasons - maybe the senior engineers are overburdened with other work (or don't care), maybe the project manager or team lead wasn't asking if the junior needed help, or maybe the junior was lying about their progress.
Either way, a story that goes for eight weeks feels excessive. Much, to your point, taking eight weeks to figure out that there was a bad part feels excessive. My counterpoint is that teams don't typically operate like labs. In a college lab, the objective is for you, specifically, to succeed. In an engineering team, the objective is for the entire team to succeed. That means the more senior engineers are expected to help the more junior engineers. They might directly coach, or they might write better documentation. I don't believe that dynamic is present in a lab setting.
> Should they expect a good performance evaluation?
They should expect that particular incident to not affect their performance evaluation, since it was very much not their fault.
In your hypothetical scenario, your hypothetical junior engineer went to the senior engineer repeatedly for advice, and the senior engineer did not do their job properly:
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.
This is a huge failure in mentorship that wouldn't be ignored at a company that actually cares about these things.
> They should expect that particular incident to not affect their performance evaluation, since it was very much not their fault.
What do you mean not their fault? I've seen wrong parts delivered by suppliers, so yes responsibility of an engineer who puts together a circuit is definitely checking that the parts are correct.
> In your hypothetical scenario, your hypothetical junior engineer went to the senior engineer repeatedly for advice, and the senior engineer did not do their job properly:
>> 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.
Again _never_ the equipment's fault? It wasn't the equipment it was a part. So maybe it was an issue of miscommunication? I find it hard to believe that the lab tech said it could never be the parts, considering how those things are handled in student labs, small parts break all the time.
Maybe, it's true and it was a crappy lab tech, maybe they could not imagine the part being broken, but I've seen the other side of the equation as well, when things don't work students often just throw their hands up and say "it doesn't work" without any of their own troubleshooting expecting the tutor/lab tech/professor to do the troubleshooting for them (quite literally, can you check that we wired everything correctly...).
In my experience this does not get accepted in industry. I acknowledge though what the other poster said, generally in industry incentives are different and someone would have intervened if a project gets held up for 8 weeks by a single person.
Regarding the story, I wonder what would have been an acceptable solution (apart from the lab tech possibly being more helpful?), I as a teacher would have excepted a report which would have given a detailed account of the troubleshooting steps etc. (but it needs to show that a real effort to find the cause, simply saying the lab tech couldn't help is not sufficient). Simply saying "it wasn't my fault because I had a wrong part" shouldn't just give you an A.
> What do you mean not their fault? I've seen wrong parts delivered by suppliers, so yes responsibility of an engineer who puts together a circuit is definitely checking that the parts are correct.
A student is far from an engineer.
> Again _never_ the equipment's fault?
The exact words the failed mentor used are not what matters here.
> In my experience this does not get accepted in industry.
This being the entire situation or the actions of the improperly used junior employee? Blaming the non-expert that was refused help is scapegoating.
> Simply saying "it wasn't my fault because I had a wrong part" shouldn't just give you an A.
It should give you more time.
> What do you mean not their fault? I've seen wrong parts delivered by suppliers, so yes responsibility of an engineer who puts together a circuit is definitely checking that the parts are correct.
Let's not move the goal posts, please. If you're going to use a hypothetical situation as an analogy, make sure it's actually analogous. Yes, an engineer who puts together a circuit has that responsibility, because they're an engineer. They went through the required training that makes them an engineer and not just an engineering student.
> I find it hard to believe that the lab tech said it could never be the parts, considering how those things are handled in student labs, small parts break all the time.
And therein lies the problem. You "find it hard to believe" that the lab tech could have been that unhelpful, just like the lab tech found it hard to believe that the student wasn't doing something wrong. Both you and the lab tech are behaving in a way that is inappropriate for a senior mentoring a junior.
In my experience mentoring others, the first assumption should not be that the person you're mentoring simply didn't do enough and that they should try to do better. Yes, that might end up being the case, but most of the time there's also something else that could have been done better. Maybe the documentation is not clear enough, maybe the process didn't help catch the mistake, maybe the expectations I set weren't clear enough, maybe I didn't communicate well enough.
"Go check your work again" is rarely helpful, even in the extremely rare cases where that's the only thing that needed to be done and no other improvements exist. If you're really convinced that they merely need to check their work again, guide them to it.
That's why they are junior and you are senior, because they need more guidance than you do. They will not develop the necessary insights and instincts without that guidance.
> I've seen the other side of the equation as well, when things don't work students often just throw their hands up and say "it doesn't work" without any of their own troubleshooting expecting the tutor/lab tech/professor to do the troubleshooting for them (quite literally, can you check that we wired everything correctly...)
And in turn, you're arguing that the mentor should merely throw their hands up and say "go check your work yourself". Again, even that can be said differently: "Can you explain what you have checked so far and how you've checked it?"
> Simply saying "it wasn't my fault because I had a wrong part" shouldn't just give you an A.
You are drawing a lot of your own conclusions from what hasn't been said. In this comment thread, you have repeatedly and consistently shown bias through your assumptions. Yes, what you're saying could have been the case, but I see no evidence of it and no reason to simply assume it without at least inquiring about it.
For a college class grade, everyone is supposed to be tested on the same exercise. If all students were tested under the same scenario then it would be fair. For just one student to be tested under this scenario, but for all other students to get a free pass on the lab component identification diagnostic test, is not reasonable.
More to the point, the professor would be required to provide the same effort to every other student in the class.
While it's ridiculous to expect a student to have the skills of a professional, even a student needs to develop assertive skills to demand a replacement part. This is a basic skill for debugging hardware problems: see if problem manifests on more than one unit. Here it would be demanding another chip to try, early-on. Chips can be marked correctly but damaged or defective.
> "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."
Hands up everyone who remembers being taught that labs were supposed to go wrong and you were doing them because you will have to troubleshoot?
... anyone?
... anyone?
... Bueller?
Or is this just the typical internet John Galt like that other guy "no offense but why didn't you just already know everything and create an apple pie by creating the universe like I would have?"
Ohm lordy, we're blaming the student for not having years of homebrew experience before he entered school? Sure any hobbiest knows what a 555 is, but when the lab assistant doesn't even catch it and the chip was handed out to the student this is not an entry-level students fault.
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.
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.
> 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.
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.
> 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.
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.
Proving the truism that incorrect documentation is worse than no documentation.
this happens in "real life" as well
i spent a bunch of time trying to figure out why my 74LS20 wasn't being a dual 4-input NAND gate
turns out that was a date code, and it was some other chip entirely
1974 was a terrible year for 74xx series TTL chips
yes, i am old :-)
This is crazy to me because when I've run labs in the past, there were equipment failures literally all of the time. When you teach lots of people, shit breaks. Quite often if something didn't work, I'd just have one student swap equipment with another student to help diagnose this sort of thing.
Major bummer that others have had differing experiences from me, here.
I had a very similar experience during a lab internship I took during my biochemistry undergrad degree.
First part of a project was running PCR on a particular plasmid that we were going to use to transfer a gene into Drosophila. But for some reason the PCR didn't work, and I spent almost all of my time trying to get the damn thing to run.
Everyone naturally assumed I was just doing something wrong, being an undergrad with little lab experience. After about ten weeks, it turned out that the lab tech had written up the protocol wrong and I was using the wrong primers. No wonder it didn't work.
Was one of the experiences that made me realise that working in a lab really wasn't for me...
I ran labs in my university in Europe, in the early 2000s, and I'd like to think this would not have happened. We were selected as tutors due to our proficiency and dedication to the subject. Maybe it was a fluke, I've heard similar stories recently about local Unis.
Honestly, you got more real-world electronics training out of that experience than you paid for. You are now qualified to deal with remarked or counterfeit Chinese parts and other inevitable supply hazards in the business. Be grateful!
Yes, maybe true. But it's a pity that was not reflected in their final grade.
That's a tragic story. However, I'm surprised that the transistor was supposed to come in a DIP package. Usually through-hole discrete transistors come in a three-lead package like TO-92. Of course, that would not have helped you since yours looked like every other student's except the for the markings.
There can be 2 or more transistors in a dip-8, but I think the point is more that the wrong dip-8 was given, not which specific dip-8.
I change details when I tell stories, both to prevent eyes glazing, and because the details don't matter that much. If I told this story to a neighbor it wouldn't involve the words "dip-8", 555, or "transistor".
For instance I had a professor that just did not like me. I did all the work, the papers, but the second paper assigned was about bioethics and at the time there was a lot of negative press about that subject and I went really deep into a subject I had never heard of before. Well the prof was a bioethicist, and on some bioethics committee, and did not like my prose. I barely passed that class that semester. I think they knew they couldn't fail me because, as I said, I did the work; but they certainly made me not want to continue college, that's for sure.
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.
> 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 would have been tempted to ask him to write me a check for the extra semester of tuition, but I'm sure that wouldn't have made the situation any better (and maybe would have made him more likely to grade strictly).
This makes me incredibly grateful for my physics lecturers, all of whom would bend over backwards to assist their students' journeys towards learning any time any stumbled or showed a spark of curiosity that needed fanning into a raging fire.
I had lecturers give me bonus marks above 100% because I noticed issues like this and thanked me for helping to improve the course material!
These lecturers, when merely overhearing a curious "huh?" conversation between students would spend hours of their own time scouring the library for relevant information and just "leave" photocopies for students to find the next day.
That's awful, and unfortunately relatable. Most of my university courses were pretty good, but I had a computer graphics course where I got about 80% for my project, and about 30% for my final grade, which meant I apparently got 0% for my exam. I was a graphics nerd, I'd written a raytracer in C++, made a decent start on a game engine in Java (including software rasterizer with perspective-correct texturing, transparency, and model saving and loading with keyframe animated forward kinematics), along with numerous games and rendering programs. This graphics course was trivial stuff and barely got past explaining what a bitmap was and how to draw pictures using API calls. I couldn't have legitimately scored zero in the exam.
After weeks of trying to make an appointment with the lecturer to discuss it (and being told "you failed, get over it"). I got an email from the lecturer, admitting that they'd forgotten to add my exam score to my overall score. And from this point, it took months further to get my official grade corrected.
This same lecturer also once emailed out grades by opening their whole-course grading spreadsheet, deleting all the rows except for that student's grade, and then saving it as a new file.
With 'track changes' turned on.