And of course after reading the code more careful-er I see that yeah I guess the order of operations would matter, to an extent - it would make the difference between a delay of timeOut (what happens) and a delay of 0 (would happen if + came before *). But that's not the point.
Neither PEMDAS or BODMAS are "wrong", they're just acronyms, meant to help you remember what you've been taught. If your maths teacher didnt tell you that addition and subtraction have the same precedence in the absence of brackets/parenthesis, as do multiplication and division, then they werent a very good maths teacher.
Perhaps "mechanical" would be a more acceptable term than "physical", though even that could be argued (as the flow of electrons is a mechanism of sorts, I guess...).
Still the term 'physical disk' for a mechanical platter (in contrast to a solid-state memory) has been in common use for years, and if "I'm not a robot" hasn't run across it before, I'd be surprised. Chalk it up to Pedantic Dickweedery, or a joke that fell flat.
My guess is that the original error wasn't quite so easy to spot, and that Mike had been using some formula that looked legit on a quick glance, but which he'd made some not-exactly-subtle-but-still-easy-to-miss mistake when changing it at some early point in things.
At the very least, it is likely that the original had a variable for offset, which it would multiply but a constant factor such as 1000 to get how much to add to the timeout. If 'Mike' deleted the leading character in the number when changing something else, he might not have noticed it later, as it would have been a part he 'knew' was already working and he never consider that it might not be working any more.
So TRWTF boils down to repeatedly failing a spot check.
Addendum 2016-12-21 12:23:
That, and failing to ask his cow-orkers for code reviews.
But as for the actual error, I'm guessing we've all been there - not seeing the mistake because we don't actually look in the right place. The problem lay not in that, really, but in his lack of professionalism in not asking other coders to put eyes on the code.
Aha! I was thinking this made no sense at all but inadvertently deleting a 1 makes sense. The time is probably in milliseconds. Expressing that as 30 * 1000 makes it much clearer what the unit is and costs nothing at runtime.
I have never understood how people manage to use hard loops as delay on actual computers.
Typically if you need timing it's a game - i.e. graphical - and then you should be running locked to the vertical retrace anyways. So an exact timer kinda comes automatically with the territory...
I really hate stuff like this. I've brought down boot processes from minutes to seconds fixing scripts that do this. They are more reliable as well. I get very angry when all I can do is sleep (although for things like network it is sometimes a must). A couple of cases still curse me today.
One is where you need to start (or ensure started) a database process but it daemonises immediately then loads which usually takes several seconds. There's no good way (or obvious good way) in a script to wait for it to finish. Thinking about it, my script is a bit flawed because it wont bail if the process dies, leaving it to time out and fail. I could make it better in places but I'd rather wait instead until I have the chance to replace the current means of persistence.
The other is a horror story. What should be a single application is a dozen applications. A Frankenstein of processes linked together from IPC. This resulted from many things, importing things from other applications, developers each doing their own thing in their own language, extreme deadlines and so on. There are a few methods for IPC, nearly all various network processes that aren't particularly useful for a cluster of applications that work together and have to run on the same machine. This means in some places to maintain consistency things like system wide semaphores are used as well as horrific hacks. Again it's one of those things you don't fix. You leave it until a rewrite is on the cards. In this case there's a process that sleeps for a minute just to hold the lock long enough to make sure the receiving application has finished processing the data before it starts consuming data from other sources that might be out of sync.
On a Linux system there are places where simply polling for something is a while lot less effort than hooking events as long as nothing is blocked arbitrarily on that polling. Out of the box Linux with init.d and the normal conventions isn't that brilliant in terms of convenience. It is improving though but gradually.
I can actually kind of see this, excluding that multiplication by zero.
Wait until you're forced to call a stored procedure to launch a job to kick off an SSIS package that runs for several minutes before abruptly failing without explanation. This is after you've spent an hour writing 20 lines of code to do exactly what you want in 20 seconds only for a manager to flip out because she expected you to squander days clicking through a package builder to get something that kindof sortof almost works, eventually, unless it crashes. You're daisy chaining this idiocy together with polling because the little dictator won't push operations to open the ports for SSIS and sp_StartJob literally just starts a job and returns immediately. And then el Stupido says "dur hur, this uploader is too confusing, users should have to browse 20 folders deep into a network share instead..."
You make a valid point about the improper use of IPC resulting from legacy practices. But you fail to recognize that most of the problems encountered "on a Linux system" with IPC are due to the fact that, on Linux, IPC is broken by design. There are some implementations where it is partially fixed, but for the most part it does not work correctly. Broken IPC is the reason Oracle database does not run on Ubuntu and some other Debian derivatives. This is one correct use of IPC. My favorite incorrect implementation of IPC is when ERP systems have a "data connector" process that employs IPC to get and send actual data between the applications and the database client driver. Needless to say, said ERPs are not able to run on Linux and must continue to run on Big Iron SystemV.
I was taught the "O" in BODMAS was operations. This includes powers, logarithms, sin, etc. I.e. sin(2x) != sin2x.
+1 for always using brackets to ensure everything happens in the order you want it to. Improves readability, and there are probably some languages out there which have their own order, likely undocumented and involving a lot of internal parsing to and from strings, in which case you pray that at least they do the brackets part first. I have a lot of mistrust for many scripting languages. I think that's healthy.