XNA: The Best Microsoft TLA Yet...

As of today, you can download XNA and build your own Xbox games.

Only the Xbox team would have the balls to give their public development framework such a cool name (XNA is a recursive acronym for XNA's Not Acronymed).

Down with TLAs!!

Morgan Spurlock's 30 Days On FX

I love Morgan Spurlock's new show 30 Days on FX.

The show takes people outside of their comfort zones and follows their experiences over the course of 30 days.

So far this season:

- A staunch anti-illegal immigration Minutemen volunteer lives with a family who migrated to the US illegally

- An ex-Morgan Stanley computer programmer who was forced to train Indians to do his job and was then fired when his position was outsourced to India lives in Bangalore with a family who works in a telemarketing call center.

- A feminist and staunchly pro-choice woman who works at an abortion clinic lives in a Christian, pro-life maternity home.

The series is from the same writer/director/actor as the awesome movie Super Size Me. I highly recommend checking it out.

Math is hard.

Today, my coworkers and I were talking about math, physics, chemistry, and the science of food over lunch.

These images my coworker passed along made me bust out laughing...











I promise, no more "stuff adam thinks is funny" posts for awhile...

OMFG: Philips Bodygroom

This interactive Philips Bodygroom ad is the most hilarious and shocking thing I've seen on the web in a long time.

It's even funnier than those tv shows about racy foreign commercials.

Go Philips and Norelco!

(Thanks Liu Shinshun for the link!)

The Construction Worker and The Architect

I just began reading Programming Pearls, a book I bought almost 2 years ago after seeing it on a recommended reading list Microsoft sent me after I'd accepted their job offer.

I've been reading and working through the problems in one chapter every day. It's incredibly engaging and fun - a cross between my old computer science exams in college and a more challenging version of those puzzle books I used to pick up at airport news stands as a kid (ok, I admit.. I still pick them up sometimes).

I feel that I'm at the tail end of a generation of computer programmers who were able to witness a paradigm shift in software programming. The first programming languages I learned were gwbasic/qbasic/Batch programming (cool! I can make a computer do stuff!), followed by Pascal and C (needed to mod my bbs!), C++ (high school AP and college classes), Perl/PHP/bash/tcsh (cool! I can make computers do even more stuff super-quickly and build web-apps!) and finally C# (project work during senior year of college, and Microsoft-land).

The paradigm shift I'm referring to though is mainly tied to the decrease in the amount of knowledge required to make a computer "do stuff". With the introduction of simpler languages like Visual Basic, and frameworks like .NET, 80% of the programming ability that was once required to build and end-to-end solution is no longer necessary (I've used Microsoft-centric examples here, but this is undoubtedly a platform-independent phenomenon that pre-dates both VB and .NET).

Even the most complex of operations continue to become simpler. Let's look at 2 examples I stumbled upon recently...

Example 1: Sorting an Array of User Defined Objects

Let's say you have an array containing username strings. Once upon a time, you, the programmer, would write your own sorting function if you wanted to order these strings. Modern programming frameworks have built-in functions to sort arrays of strings, and you don't need to know a single thing about sorting algorithms.

Okay, so now let's say you've created an object (i.e. a struct, class) to represent a "user". It contains a username string, and a whole bunch of other information like a full name and email address. In the not so distant past, you, the programmer, would write your own sorting function if you wanted to order these user-defined user objects (because the programming framework did not know how to sort your object (should they be sorted by username, by full name, by email address?). Modern programming frameworks allow you to implement a comparison function (i.e. IComparable.CompareTo(), which will be used by the framework's built-in sorting functions to sort your user-defined object.

Example 2: Multithreaded Windows Forms Programming

It used to be the case that if you wanted to build even the simplest Windows Forms application that did something time-consuming in the background without locking up your UI, you needed to master the art syntax of making asynchronous calls with delegates and callbacks. With the introduction of the new BackgroundWorker component in .NET 2.0, it's pretty easy to build simple multi-threaded WinForms applications.

So, getting back to my point here, 80% of what once required significant programming ability (i.e. ability to devise a sorting algorithm), now requires significant programming framework domain knowledge instead - something which, in my opinion, is much easier to teach and learn (and it is now probably most of what is taught and learned at trade schools and training classes).

So what about the other 20%?

I believe that this is where the true value of a software engineer still lies - along the lines of the Pareto principle - where 80% of value is brought by 20% of resources. Lots of people out there have the knowledge and tools to be a construction worker, but how many can architect a skyscraper?

At The University of Michigan, I spent 4 years studying Computer Science, and learned nothing about Visual Studio, C#, .NET, or many other skills required to function as a Windows software developer today. In their place, I learned about propositional and predicate logic, set theory, function and relations, growth of functions and asymptotic notation, combinatorics and graph theory, discrete probability theory, techniques and algorithm development and effective programming, top-down analysis, structured programming, testing, program correctness, program language syntax and static and runtime semantics, scope, procedure instantiation, recursion, abstract data types, parameter passing methods, structured data types, pointers, linked data structures, stacks, queues, arrays, records, trees, algorithm analysis and O-notation, priority queues, hash tables, binary trees, search trees, balanced trees and graphs, searching and sorting algorithms, recursive algorithms, basic graph algorithms, greedy algorithms, divide and conquer strategy, instructions executed by a processor and how to use these instructions in simple assembly-language programs, stored-program concept, datapath and control for multiple implementations of a processor, performance evaluation, pipelining, caches, virtual memory, input/output, finite automata, regular languages, pushdown automata, context-free languages, Turing machines, recursive languages and functions, computational complexity, database design, integrity, normalization, access methods, query optimization, transaction management and concurrency control and recovery, and much much more.

Getting back to the paradigm shift... I think the short of it is that abstracting out most of the underlying knowledge and ability to engineer great software is a great thing - especially for professionals who view "software engineering" as a means to an end, rather than the end itself.

But for those out there who are looking to engineer truly original, scalable, and otherwise high quality software, Programming Pearls is reminding me so far that a great set of tools, and knowledge about those tools, can't replace an underlying depth and breadth of knowledge and ability of a true computer scientist.

I'd highly recommend every software developer reading this blog check out the book...

The Design of Everyday Things

Let it be known that I am a very gentle book critic. I'm humbled by the wealth of information out there. I expect that I still have a lot to learn from a lot of people on a lot of subjects, and if I can pick up a book and learn even just a few new things, I'm satisfied. If the book is engaging, if I learn many new things, well, that's all bonus. You can see a list of books I've liked on the right-hand side of my blog - most of which I've given positive reviews at some point on this blog.

As gentle of a critic as I generally am, I must say that The Design of Everyday Things (I won't even link to this book's Amazon.com page) was a huge disappointment.

Originally entitled "The Psychology of Everyday Things", it was later renamed to sell more copies. Since the time I picked it up at the book store about a month ago, it also seems to have gotten a Web 2.0-ified new cover...

Old cover


New cover


Author, and "expert" on all things "design"


The way this book read was as follows.. the author seemed to have a huge pet peeve, bordering on obsession, with everyday things that were not designed with their intuitive factor trumping all other factors (physical appeal, price, etc). The chapters are a succession of rants, calling out widely-known problems (VCRs are hard to work, rows of light switches are confusing), and providing less-than-creative-or-optimal solutions (add an on-screen display for the VCR, mount a custom-made switchbox on the wall that looks like the map of a room - right - elegant).

The author rants about a panel of flush cabinets (which, let's say one would open by pushing to pop out or by grasping the bottom and pulling) because there is no visual indicator (i.e. a big bulky handle!) as to how to open them.

I completely agree that things should be intuitive to use. I shouldn't have to learn how to open a cabinet. That said, intuitive shouldn't necessarily trump beauty, cost, or any other factor. I don't mind taking a second to think about how to open my kitchen cabinets for the first time if they are beautiful kitchen cabinets.

Rarely is a good solution "either intuitive or elegant | simple | beautiful | inexpensive".

Unfortunately, I didn't learn anything useful from The Design of Everyday Things. I didn't learn how to design things better - just that "things should be intuitive to use" - duh. I hardly enjoyed reading several hundred pages of rants on the subject. I think the book is marketed extremely well, and that the name is quite deceiving. Most namely, while there is a science to design, the act of designing great things also involves some level of creativity and ingenuity - something I felt was passed over by this book.

Before wrapping up this rant, I'd like to provide an example of an elegant everyday-thing design - the Trofé mug from IKEA (by way of Apartment Therapy LA):


I own 4 of these 50 cent mugs. The small notch at the base allows the water to escape while drying upside down in my dishwasher.

Simple, elegant everyday-thing - one you won't learn how to design by reading a book (or not this book, at least).

A Gray Twilight

A quote I came across at the beginning of the 5th chapter of Built to Last...

Far better to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory, nor defeat.

Theodore Roosevelt, 1899

When you read this quote, how does it resonate with you?

Have you dared mighty things? Experienced glorious triumphs? Are your winnings checkered by failure? Or... are you living in the gray twilight?

The biggest risk I've taken in my professional life was dropping out after 1 year of college at age 19 to work at a startup in Silicon Valley in 2000 (and in the process, turning down a comparable offer from rising dot com star Excite@Home, which tanked shortly thereafter). The second biggest risk I've taken was later walking away from that job (and my 21-year-old $82,500 salary) to go back and finish school (the startup tanked shortly thereafter).

I went to work on this beautiful Saturday morning. The hallways were silent and dark - far different than the overcrowded EECS computer labs in college or the large, open engineering workspace at the Valley startup. I looked around for someone to get lunch with, and quickly realized it wasn't gonna happen. So I went to the Teriyaki restaurant around the corner, next to the big company that employees 30,000+ locally, and sat in the empty restaurant, eating alone.

The biggest risk I've taken in the last 15 months has been deciding in which funds to invest my 401K. How about you?