Comment by realo
Comment by realo 3 days ago
ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them!
Trust, but verify.
Comment by realo 3 days ago
ALWAYS suspect some fuckup on the part of the knowledgeable people... especially them!
Trust, but verify.
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.
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.
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.