It's actually fairly readable if you have a background in coding at all. Here are some clues:
1. Every built in in Javascript can be overwritten.
2. If you see something like ObjectName.prototype.fnName, then what you're doing is defining a new fnName function on ObjectName. The thing about Javascript is that you can add new functions to objects, and since everything can be overwritten, you can also replace old functions with new ones. So when you do something like Array.prototype.sort = function(){...} then you're overwriting the builtin sort method on Arrays. Most of the script is just defining builtins to have bogus results.
3. Javascript has a built in Math object, like a few other languages. The language also allows you to create objects on the fly with bracket notation: the layout is key: value. So the Math definition defines Math.PI to be 3.2.
4. There are a few other jokes in there too (like defining alert, which makes a message box, to be eval, which evaluates the string).
It does... many things. All sort calls are hardcoded to return [4, 8, 15, 16, 23, 42], regardless of input. It scrambles the log bases for the math logarithm commands, it hardcodes the output of the upper-casing string call to a constant, and what I've reported is just a sampler. It is very well-named.
Could be improved a bit, though. Many of its entries lack subtlety. If you really want to be evil, make uppercase do something like uppercase all but one letter, or "uppercase" the digit 1 into exclamation marks, 2 into at signs, etc., convincing the poor developer that the JS upper case function is broken and affect digits. ("Must be unicode or something.")
How would this not start a backlash of "JQuery (or whatever) is broken."? If the only indication is that a hotlinked .js suddenly stops working, what exactly is the debugging process there? I simply don't think most web developers are going to find a useful path from "scrambled log bases" to "hotlinked js," if they even identify "scrambled log bases."
Then again, maybe the point is to muddy your own waters? I'm reminded of an aphorism dealing with activities that should not be undertaken near one's place of slumber.
From my inexperience (3 years at one company, 1 year at another), the sad truth appears to be that the developers would care just enough to hide the problem.
For example at my last job, I was pair programming with the "most valuable" C++ programmer. We were debugging one of his monolithic heightmap classes. Some top-level method was calling some deeper method that was doing a lot of different complicated things. After examining the top level method in the debugger, and looking at the results after calling the deeper method, he wrote some code to "patch over" the problem. I.e. The deeper method was causing the results to be bad in some way, and his solution was to add code to overwrite the bad results with the expected ones. Then we ran the program and it worked.
To my surprise, he stopped there and committed the code. As he was writing the commit message, I asked "Hmm, aren't you interested in why the internals don't seem to be working properly?" He shrugged and said "No."
I hear their game engine has suffered rather severe performance problems and general bugginess. It also looks visually to be 2004-era.
