We often talk about dates and timekeeping as extraordinarily difficult tasks. And, at least in part, that may have to do with their origins as legacy technologies in the most legacy sense: we have strong evidence of calendar systems all the way back into the Neolithic period, and maybe some hints of them as far back as the Paleolithic. Literally, stone age technology, still in use today.

I wonder if that's why calendar's hold such a mystical hold over us? Many of us likely remember the New Age predictions that 2012 was going to mark the end of the world or some great reconfiguration of the world, simply because it marked the end of a cycle in the Mayan Calendar. Before that, prophecies centered on the year 2000, not just because of the Y2K bug, but simply because it's a round number and people felt like that's a good place to call it. Before that, there was the astrological predictions of the Age of Aquarius (which may fall anywhere from 1844 to sometime in the 24th century, but was real popular for a minute in the 60s and 70s). And we can walk farther back into history, finding eschatological predictions centered around significant dates.

"Generic exception handlers" sound like an oxymoron, but are a weirdly common pattern in web development. ASP .NET, for example, has a global.asax file, which can contain an Application_Error method. In practice, this is meant to handle all the otherwise unhandleable errors- each individual endpoint should still do exception handling for all the errors it can, but the errors that are impractical to handle locally, like the database being inaccessible, bubble up to your generic handler.

Of course, it's important that the generic handler actually handle the exception. Which brings us to George's submission, an ASP .Net error handler.

Before today's article, I'm gonna humblebrag a bit, minus the humble part. Peregrine launched last night, at 2AM, and by 3AM, we had communication with the spacecraft. I have done very little software on this particular mission, but code I touched is in space right now. My name is on a plaque on that lander. Also, the code I touched has no control over the mission, and is in no way, shape, or form in the control loop, so if anything goes wrong it's definitely not my fault.

Mac bears some responsibility for today's code, in that, he "fixed" it. That is to say, he was working on an unrelated bug, but this particular block of code was causing additional problems, so he did the bare minimum to make it stop bothering him so he could work on his actual ticket.

This JavaScript running on their page would allow the user to check a checkbox, navigate away from the page, and then if they hit "back" (something Mac was doing a lot while debugging), the checked checkbox would gradually migrate down the page for some weird set of JS and CSS reasons.

Christian works on an application that has some unusual conventions. For example, while I've seen many a codebase that Hungarians their private member variables like _myPrivateMember, his team did the opposite: myPrivateMember_.

Someone on the team had a problem: they needed to verify that at least one checkbox was checked. This was their solution to that, in C#:

Matteo's company hired a Highly Paid Consultant. The HPC came in, took one look at their C# codebase, and said, "You're doing everything wrong. But don't worry, I can fix it!"

So he "fixed" it.