Update: this is the Google explanation (thanks Ofer).

While casually indulging in my favorite Saturday afternoon pass-time of Googling for... myself, I was rather surprised by the unusual results:

What? pashabitz.com may harm my computer? *My* computer? How? Wait. Every single result there seems to hold the power of hurting my computer. Do you have something against Pasha Bitz, Google? Or are you just trying to protect me from a severe case of Narcissism? And what happens when you do take the horrible risk and click the deadly link?

At my own risk?? Oh my. Will I be able to resist the temptation? Lets try something else:

Oh-ho. All of this is also extremely harmful for my precious innocent eyeballs and mind. What about Google itself?

Harmful again. Even Google itself! Reader, maps, google.co.uk. But wait, I am in Google right now. So how is this possible? Is it not self contradictory? Does it mean Godel was right? Is the universe about to collapse onto itself at this very moment? I was totally unprepared for this!

Luckily, I know some people working at Google. I examined the source code carefully and traced the problem to the following lines of code:

Left: Rembrandt, A Scholar, 1631, Oil on canvas.
Right: Me, picture by Aviel Lazar, 2009.

There are few reasons to have your code log extensive error/debug messages. One of them is to help with debugging issues on a remote (or worse, production) environment. Here are some tips to help you get the most out of this kind of logging:

Log Actual Values

With a well placed log message you will be able to easily pinpoint the line of code where the problem occurred. Now you're left staring at that line of code and trying to guess what caused the error. This will be so much easier if you include in the log message the actual run-time values that your code worked with. This includes stuff like the parameters to the method, fields of the class, session values etc.

Log at Component Boundaries

A component can be a different .net assembly, code that resides in a different logical layer of your application, a third-party library or a piece of code you communicate with using anything than just a method call (like HTTP or WCF). Wherever there's communication between two components, there are bound to be "wiring bugs". Because most components are well thought-out and tested on a standalone basis, it is very useful to know what data was exchanged to help with debugging the issue. Always log all parameter values, both on the client (caller) side and the server (called) side.

Log at Organization/Responsibility Boundaries

This is a slight variation on the previous suggestion. Whenever a call is made to a piece of code owned by another person or group, you should log all parameter values. When you walk across the hall to ask the owner of that code about the bug you're trying to fix, the first thing they'll ask you is what are the exact values you're sending in.