This is part of a constellation of symptoms that I attribute to the Senior Engineer Field Effect. Other symptoms may include being unable to demonstrate misbehavior, losing the requirements out of your head, and solving a bug that has been bugging you for hours.
> The phenomenon that something which was previously working correctly, suddenly does not work correctly when one tries to demonstrate the operation to others.
the same word is also used for the reverse situation, i.e. if something that did not work suddenly works when trying to demonstrate the failure.
think bug reporting e.g. at the car mechanic, warranty claims, etc. if you try to show a reproducible bug to others, it suddenly vanishes...
i've never seen it used for pleasant surprises. its basically if you want to show something (even something that does not work, like the engine-not-starting) and the demonstration does not work as expected.
That could probably be called a Heisenbug[0]: A bug that disappears or alters its behavior when one attempts to probe or isolate it.
Though it depends on the cause - as others in this comment chain said, if it's just that the file isn't actually being updated between tests, but adding a new line forces an update/recompile/etc., I'm not sure what you'd call it.
Another common cause is that the code you were looking at wasn't actually the code you were running. Between "I added this line and then I removed this same line, and now it works", the executable might have been recompiled.
What's the equivalent word for "Your computer suddenly becomes slow and unresponsive, you try to open Task Manager (or run `top` in a terminal) to see what's bogging down your resources, but the resource monitor itself refuses to respond for a few seconds until the lag vanishes, at which point the utility finally renders and everything under the CPU/Memory utilization appears normal" ?
That's a temporary system stall when some critical part of the system is overloaded or blocked, usually the disk.
Or an out-of-memory condition, the system recovers when the OOM killer has killed a random process. If you were lucky that process was your game hogging ressources and when it went away the system recovered.
And for impressive German words? "Systemaufstauung mit urplötzlicher Lösung" (system bottleneck with sudden resolving), "Speicherüberlastung" (memory overload) or "Prozessabmurkser" (process terminator).
Note that I invented these words (oder auf gut Deutsch, ich habe mir diese Wörter aus den Fingern gesaugt).
If you anticipate that this will happen when you open task manager, possibly because it has happened before, you start chanting in German “watch me, I’m about to pull a trick 17!” before opening task manager, having ensured that the whole room is paying attention whether you succeed. When people ask how you knew or why it worked you just shrug smugly to hide the fact that you don’t actually now, and let everybody bask in your aura.
I wrote this prayer to appease the Demo Gods [1]. Though one might pray, the demo can fail.
O Lambda the Ultimate, bless we who are in this demo...
That our core be functional,
and our functions be pure.
That our data be immutable,
so we may know the value of values.
That our systems be composable,
so they may scale with grace.
That their States only mutate
in pleasantly surprising ways.
That the networks and servers stay up.
Well, at least through this demo.
For otherwise, nothing lives, nothing evolves.
In the name of the \alpha and the \beta and the \eta...
\(\lambda x.x x\) \(\lambda x.x x\) ; eternally
A related thing that happens a lot is when the demo is way slower than it was when you were testing it. But at least this one can be explained by screen sharing applications adding latency to your refresh rate. It really is slower when you share your screen!
Readit News
All by the mere proximity of a Senior Engineer.
the same word is also used for the reverse situation, i.e. if something that did not work suddenly works when trying to demonstrate the failure.
think bug reporting e.g. at the car mechanic, warranty claims, etc. if you try to show a reproducible bug to others, it suddenly vanishes...
* My code doesn't work and I can't find the bug even after over an hour
* I add a few lines of <whatever code>. Now it works!
* Now, just for comparison, I remove all the code I just added (or, at least I think I reverted back to previous state). But now it still works.
???
Though it depends on the cause - as others in this comment chain said, if it's just that the file isn't actually being updated between tests, but adding a new line forces an update/recompile/etc., I'm not sure what you'd call it.
[0] http://www.catb.org/~esr/jargon/html/H/heisenbug.html
* The program works flawlessly
* Somebody finds a bug on the code that is executed in a test
* The relevant test now fails consistently
Both are probably because you changed something on the environment when you looked at the code.
Makefile (or a similar build system which uses timestamps) + a problem with wall clock -> stale files.
Deleted Comment
https://quentin.delcourt.be/blog/2020-01-22_demo-effect/
https://www.urbandictionary.com/define.php?term=demo%20effec...
Or an out-of-memory condition, the system recovers when the OOM killer has killed a random process. If you were lucky that process was your game hogging ressources and when it went away the system recovered.
And for impressive German words? "Systemaufstauung mit urplötzlicher Lösung" (system bottleneck with sudden resolving), "Speicherüberlastung" (memory overload) or "Prozessabmurkser" (process terminator).
Note that I invented these words (oder auf gut Deutsch, ich habe mir diese Wörter aus den Fingern gesaugt).
O Lambda the Ultimate, bless we who are in this demo...
[1] Slide no. 5 here: https://github.com/adityaathalye/slideware/blob/master/n-way...(edit: formatting)