Mahjongg and Me

Ever since switching my primary development machine over to Ubuntu, I’ve developed a nasty habit of firing up Mahjongg every time I have to watch logs or wait for a task to run for any great length of time. Even for an old, jaded gamer, it’s a surprisingly fun and challenging quasi-distraction: just engaging enough to keep me from feeling bored, and not so engrossing that I lose track of the logs flying by on my second monitor.

Just because you can’t have too many justifications for newfound distractions, I also realized that the game teaches a very valuable lesson for startup types, programmers in particular. For those not familiar with mahjongg, the goal is to remove exposed tiles in matched pairs from a specially shaped stack. There are four of each type of tile, so throughout the game you’ll have several options of which of the four to remove as pairs. The real trick is that every time you remove the first two of four tiles, you’re critically limiting your furture pair matching ability for that set, since now you -must- pair the remaining two.

A player in this kind of environment learns several important things. First, you cannot play safe - there’s no way to win the game by leaving all your options open, and crafty stacks obscure difficult challenges you may face in the future. Therefore you must play smart, and you play smart by only making moves that make a future move possible. Each pair removed should expose one or more tiles you -know- you’ll need for a move in the future…removing pairs just for the sake of their removal often causes you to lose the game.

This is also a sound strategy for a startup. You start your company early with a whole world of options in front of you, but resources to only pursue a few. Pursuit of one option often removes several others, and so each step you take should set up one or more future moves. Randomly exploring possibilities will, more often than not, ultimatley prevent you from reaching your goal.

For startup programmers, this lesson is all the more poingiant. There are always libraries, routines, and architecture that require our attention, and we lack the resources to merely peruse our to-do list until all items are finished. Instead, we must choose what architecture to make robust for worry-free scalability and which we can hack into place. If you over-optimize the wrong code, those you neglect will haunt you during your first traffic spike. We must think three steps ahead to see which routines might benefit from being rolled into a library for better portability and which will survive with judicious copy/paste solutions. Choose wrong and a future tweak to your logical, not fully realized, will irrecoverably corrupt your data.