I am always hesitant to incorporate too many debug logging statements in my code as it tend to clutter the code, sometimes get left turned on in production where it can dramatically slow down the system, expose confidential information and also consume all free storage space quickly. Of course, if done properly this is an incredibly powerful aspect of system design.

I was reminded today how important it is to have this looking glass built into systems, especially background processes. I had created a system that integrates many disparate systems, and communicates almost exclusively using REST API calls. However, one feature was not yet turned on, so the code followed a logic path that I did not anticipate at the time. In the end, the system ended up making hundreds of API calls per second to a specific service endpoint for days on end, without me knowing.

I started picking up that something was amiss as every day I would get one or two notifications that the API call failed - due to timeout, internal error or other reasons. However, that method was being invoked by any of up to 30 different callers - so tracking it was very hard.

At least, that is what I'd like to believe. Sometimes self-deceit is bliss. This little 562hp, ¼ million dollar monster helped me in my quest:

I just do not get it. Just because logically the province is usually written before the country, it does not imply it is a good idea to blindly follow convention when implementing an address capture form.

Forcing people to first select a province (which is defaulted to the list of provinces based on the defaulted country), is meaningless for everyone not living in the defaulted country. And no America - you are NEITHER the only country in the world NOR the biggest. I always have to scroll past province, then select my country, then scroll back up to province and change it.

Country should be first. Then province. Stop this madness.

I just received an email from LinkedIn, with this paragraph:

LinkedIn has taken significant steps to strengthen account security since 2012. For example, we now use salted hashes to store passwords and enable additional account security by offering our members the option to use two-step verification.

The problem with this statement, though very beneficial to someone like me, is pretty useless for anyone not familiar with cryptography. Do you know why "salted hashes" are better than "normal hashes"? I bet 99% of the population that received that email, do not know the difference. If I were them, I'd rephrase it as: