Since almost everything we do is a stepping stone to enable something higher-level, something with more significance than what we’re working on at any given moment, its elegance should be appreciated and then it should almost disappear. If you’re having to pay attention to the tool – the screen, the verbiage, the lower-level API routine, even a door handle – then that’s attention that you (or your target audience) will be unable to bring to the problem you’re actually trying to solve.

Properly understanding the use of date and time within a system is one of those areas that looks simple initially, then looks quite complex, but if you approach it in the right way can get downright simple again.

There’s a lot of available information talking about different types of database technology, how to format your data, how to index it for fast retrieval – you name it. At this point though I’d like to talk about something a little more abstract: what to store, and where to store it. One way to divide data that I strongly recommend you follow is to always keep in mind whether a piece of data is unarguable fact or business-logic derived opinion.

There’s a lot to learn about character encoding – the good news is that unless you really want to do so, you shouldn’t bother. If you’re looking for a recommendation, just use UTF-8. Its rapidly becoming the new ASCII because its reasonably efficient, supported by everything, and can comfortably handle transmitting every character a modern font might support.

I was using a third party system this weekend – naming no names – and it managed to frustrate me by the way that it handled a lagging UI experience.

There’s a post going around that I’ve seen a couple of times now about “being a gentleman”.  As a man myself and a father of two sweet girls,