3 ms·

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 t

by Isamu 2y ago

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.

realo 2y ago
ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them! Trust, but verify.
- nomel 2y ago
  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.
  - wasabi991011 2y ago
    I would love to hear some of your examples, if only to reinforce your lesson to myself.
    - gopher_space 2y ago
      “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.
      - mook 2y ago
        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.
        Baeocystin 2y ago
        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.
      - _carbyau_ 2y ago
        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.
- deleted 2y ago
  [deleted]
- kirubakaran 2y ago
  "Trust, but verify" is just a polite (ie corporate) way of saying "Don't trust until you verify", right?
  - thaumasiotes 2y ago
    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. Trust, but verify: 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. You can't finish step B until you have all the prerequisites, but you can start it.
  - jodrellblank 2y ago
    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.
cycomanic 2y ago
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?
- CodeMage 2y ago
  > 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.
  - cycomanic 2y ago
    > 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.

by Isamu 2y ago

realo 2y ago

ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them! Trust, but verify.

nomel 2y ago
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.
- wasabi991011 2y ago
  I would love to hear some of your examples, if only to reinforce your lesson to myself.
  - gopher_space 2y ago
    “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.
    - mook 2y ago
      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.
      - Baeocystin 2y ago
        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.
    - _carbyau_ 2y ago
      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.
deleted 2y ago
[deleted]
kirubakaran 2y ago
"Trust, but verify" is just a polite (ie corporate) way of saying "Don't trust until you verify", right?
- thaumasiotes 2y ago
  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. Trust, but verify: 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. You can't finish step B until you have all the prerequisites, but you can start it.
- jodrellblank 2y ago
  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.

cycomanic 2y ago

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?

CodeMage 2y ago
> 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.
- cycomanic 2y ago
  > 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.