When I was at college, in the library on the wall above the photocopier was a big red button with a sign that said "Do Not Press This Button" -- you would be amazed how many folks did press it just to see what happened (I think it was part of some psychology class/experiment).
When I'm giving a talk to non-engineers, I often tell them that half of the fail-safes we build into our systems are there to tell us when some drongo has turned the other half off :-)
This is not actually a technical practical joke but it did occur in the technical work place. I call it joking the jokester. One year at Easter time I came to work and found a beautifully decorated Easter egg on my desk. The other people in the office also had eggs. I asked around "who brought in the eggs?". I found out it was the young lady in charge of our spec department, someone who I had played a number of practical jokes on. So after finding out who left the eggs I decided I had better check this out. I took the egg on my desk and tried to spin it on its end. It just flopped over, indicating a raw egg! I double checked a egg on her boyfriend's desk. It spun very nicely on its end, a cooked egg! I then very quietly switched eggs with her boyfriend & clued in others in the office. We had a good laugh when she was trying to explain the raw egg to her boyfriend & helping clean up the mess!
I worked for a small electronics controls company. We built our own products and did custom contract work. We needed extra help, so the boss hired a "techno geek" who claimed to be able to do drafting. He was so slow, the system was being built before he had drawings. This job required a control console that was larger than most Craftsman roll about tool carts. We had it set up for testing against a wall. When the boss told him he would have to turn it on and test it because of his delays, we had drilled a hole through the wall and put plastic tubing through the hole and into the control panel. One of the guys was behind the wall with a cigarette. As our "draftsman" pressed the Start button, smoke started billowing out the panel. You should have seen him panic trying to figure out how to turn it off. I don't remember that it got him to speed up any, though.
In the old days at the cape, a "button pusher" was cured when a dual indicator button was put in his reach. The top half said "Press to Arm". When he pressed it, the bottom lit up with "Release to Destruct" displayed. He was left holding the button down for some time.
At one job it became obvious to me that somebody was doing things on my computer when I was not there. This was a problem because I was writing code to be compiled, and if they opened a code file with the editor in the wrong mode, it would insert control characters, which would cause compile errors. Management assured me that nobody was doing this, and that I was just stupid. My response was to build an alarm system using a large electric bell and a car security alarm siren, and a 30 second delay after triggering. The whole system was plugged into an outlet that was hard to find. The trigger relay was plugged into the plug-strip that powered my computer. One morning a few days later I came in and got a lot of funny looks from quite a few people. But I never had any more problems with people using my computer. I should point out that each of us was assigned our own computer which we were totally accountable for.
Nice that so many of you know what life was like in the '60s.
We had an incident in the electronics development lab where I worked when one engineer had persistent problems with the tuning of the filters he had designed, finally traced to supply voltage instability. I had wired all stations along the benches to supply plus and minus 5 and 11 volts dc, stabilised; our design standard for the new fangled transistors that we were using. The supply circuits used a neat overload cutout that reset automatically when the overload was removed but we had never considered the fact that the series regulating transistor became quite hot during the overload and would therefore pass excessive leakage current for a short while after the supply was restored, raising the voltage temporarily out of spec. This was happening because one engineer persisted in using a design that overloaded the supply but he didn't tell us when it had happened. My remedy was to connect a particularly strident alarm bell to operate whenever the cutout was triggered. And THAT had to be manually reset. The sinner protested loudly at this development but was firmly suppressed by the rest of the team. The bell remained but the need for it gradually declined.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.