11:15, restate my assumptions:

1. Mathematics is the language of nature.
2. Everything around us can be represented and understood through numbers.
3. If you graph these numbers, patterns emerge.

Therefore: There are patterns everywhere in nature.

Ever since reading The Design of Everyday Things by Donald Norman I’ve looked upon everyday objects with a newfound insight into their subtle yet significant design flaws.

For instance, the elevators at my office have a sleek control panel in brushed steel. Modern in appearance, minimalistic, utilitarian, and robust.

It’s usually the details that make the difference in design, and this interface has some subtle shortcomings:

1. Poor contrast of the engraved markings makes them difficult to read.
2. Restricted viewing angle of the light for each button makes it difficult to see what floors are already selected when at the front of a packed elevator.
3. Minimal differentiation between the “door open” and “door close” decals makes it difficult find the correct button to hold the elevator for someone as the doors begin to close.

Not that, I’m not complaining. There is worse design elsewhere.

Since an overwhelming majority of poll respondents indicated that they "get paid to do geeky things" I figure I it is safe to post on some more technical subjects, such as the book which I recently finished reading at work. (I've been struggling to find chunks of time to read this book, having started it over a year ago, so I'm glad to finally have finished it.)

Framework Design Guidelines, by Krzysztof Cwalina and Brad Abrams, encompasses a lot of the hard lessons that were learnt in bringing the .NET Framework to us. Building an intuitive and powerful programming API is a non-trivial activity, and a lot of people underestimate the importance of framework design and design testing.

This book explains a lot of concepts that are relevant to .NET developers (even if you're not explicitly building a framework) and boils each area down to a set of easy-to-understand "Do" and "Do not" rules (a lot of which are captured by the automatic analysis of FxCop and its successors).

If you want to learn from the mistakes at Microsoft, understand design principles, and build robust, easy-to-use APIs with .NET, then I'd recommend you read this book.

(There's even a Second Edition on the way, "to cover the new features in the .NET Framework 3.0, 3.5, and new advances in languages (e.g. LINQ) that are relevant to Framework design.")