34
votes
When you show the engineer and it works
We have all done it and seen it happen but I don't know its name
Someone has tried and proven that something just doesn't work, it is broken. And so you call the engineer and the first time you try to demonstrate it, it works and then works afterwards every time.
It isn't Murphys Law and it isn't Sods Law but what is it?
I call it Engineer Syndrome but that cant be right
When I was working help desk, we called it the "tech aura". Where as soon as we show up, all the user's issues suddenly can't be reproduced.
Similar idea, we told the user that the very act of calling IT could fix the problem. The computer knows we're going to be monkeying around with it's internal settings if it isn't working, so it decides to be good.
There's different levels of aura too. I've had a T1 guy's issue work as soon as I walk over, and then sometimes my issues get fixed magically as soon as the T3 guy walks over. It's fucking bizarre. I've had an issue once where I drove 45 mins to look at a PC that worked when I was there and as soon as I left it stopped working. That one was possibly a PEBKAC but it behaved so strangely.
This is probably the best name I've heard for it.
Super common within the service desk I look after both internally and externally
We actually call it the same in our family and circle of friends.
(Switzerland here)
while @kru mentioned the "stepping through slowly" effect, I have also seen it work on one-step problems.
No idea what is happening, but my wife hates me for it.
In German we call this the Vorführeffekt (demonstration effect).
Of course there’s a German word for it. I love that.
I like this one and I am going to use it in day to day life
Thank you
In academia we have the opposite effect - the negation field.
This is definitely in software as well, where everything works fine for weeks and then you try to demo it and it fails.
Happens everytime.
Private Survivorship Bias. Private being all the dozens of failures and it succeeds once or twice is counted as a success. Thus, when you demonstrate it to someone else, it fails because the odds were always against you lmao. This is why extensive automated testing and control is crucial - to remove human short-term memory bias of failures.
It's sort of like a form of Rubber Ducking. You take a breather and then try to explain the problem to someone else, usually from the start or from a wider context than that which was causing you frustration to begin with. In doing so, you solve the problem on your own.
While rubber ducking is a legit strategy for solving problems, I don't think it relates to what OP is mentioning. Here, the problem gets solved on its own, without intervention of any kind. Usually, these problema are something that rubber ducking won't help at all, because you need technical assistance to fix it, not just frame your mind differently.
I think it's similar and does relate. When the user calls you over to explain that something isn't working, and they try to show you the problem, they'll often have to start from a sort of beginning step, which isn't something they'll do on their own. For example, the user calls you over and claims a button on the internal site doesn't work. You ask them to show you. They open a browser, log in, and click the button and, it magically works this time. This could happen with an expired session ticket or something which got refreshed when the user stepped through the login process to demonstrate the error.
One real example case that I recall was from a long time ago. I was working for a lady who owned a small business finding spots for corporate executives. She would always call me over and claim the printer wouldn't print for her, but when I'd arrive, it would work just fine. It took about 5 or 6 times of this happening for me to figure out that she was turning on the printer and trying to print immediately, not giving it enough time to boot up (this was way back when printers had their own lengthy boot cycles). But, by the time I arrived, the printer was booted up and listening properly on the network, so the "tech aura" magic made everything work. By having to call me over to show me the problem, she inadvertently and unknowingly solved the problem on her own. It's similar.
I am not sure but I think my proudest moment was when one of the engineers I was mentoring referred to me as their Rubber Duck in a meeting and then had to explain the theory to the Directors that were sat there.
Since then he has been given gifts of rubber ducks from all over the world and has an extensive collection.
I don't have a name for it, but I think it's temporal, rather than proximity based. Running a LAN center in Phoenix for years, I developed the habit of every time someone said they needed help I would deliberately count slowly to 10 in my head before walking to their computer (30 if I didn't like them). 7 times out of 10, the problem "magically" resolved itself before I got to the desk as they either A) found the thing they couldn't find or B) waited long enough that the computer finished doing whatever hidden task it was doing and resumed the thing they actually wanted it to do
In my experience this is called user error until proven otherwise.
Disclaimer: am engineer, so I may be biased
Heh, that's me too.
Operator: "Hey guamisc, the process isn't working and it won't let me progress to YYY step"
Me: "Did you let XXX step complete correctly by itself or did you manually terminate it?"
Operator: "It was done by itself!"
Me: "Ok, well run XXX step again, I'll watch it"
<5 minutes pass, XXX step finishes it's task, YYY step is now available>
Me: "Check now"
Operator: "Thanks guamisc, it works now"
They manually shorted XXX step the first time by whatever hijinks they could muster to get their job done faster and then they didn't do it the second time while I was watching. Suddenly it works.
Now a lot of the time there might be something actually in need of addressing in general, but if the problem disappears when I walk over and look at it, 99.9% of the time someone isn't following procedure for various reasons, usually speed.
Heisenbug came to mind at first, but the part about the observer being an engineer and the thing always working afterwards make it a specific subset of heisenbug.
It reminds me of a real incident when my company's internal DB went down but only on specific pages. When I sent in an email the receptionist (she filters requests so only important ones get passed up the chain) came in, opened the DB, and then obviously would have left saying nothing was wrong - I had to navigate her to the specific page so she'd have to admit the problem was real.
I thought for a moment you meant memory pages and was going to say that must have been quite some bug.
I've been testing a few!
The Law of Computational Irony
Ironia Ex Machina
Cosmic Irony
Honestly, it's been getting to the point that I actively encourage coworkers to state to another person what they DON'T want to happen when trying to describe a bug. That way, either the bug replicates itself to spite you, or the bug will never be replicable again. I use the analogy of an unruly kindergartener - in class, they are a hellion, but on Parent Teacher Conferences they're on their best behavior.
Tech Aura is one I've used in help desk as well.