Synchronicity or Serendipity?

The week after I posted my blog on integer division I was asked for help on a problem involving linearising a sensor output. Part of the answer turned out to involve multiplying a function of the output value by some weird factor like 211/255. Well, given that I'd just written exactly the code needed to handle this sort of strangeness, this turned out to take approximately ten minutes of my day. Result.

Of course this approach only occurred to me because I'd so recently been playing with integer division code, and so made the obvious connection. Maybe given time, if I hadn't been handed the answer by the universe immediately beforehand, I would have come up with an equally valid alternative approach. But for the life of me, I can't think of a neater solution to this particular problem.

A second example of the power of autodidacticism (not as dirty as it sounds) came about the following week when I was looking at how to add new events to a client-server messaging system. Having a global enumeration of all possible events works fine, but means that you have to rebuild every darned application every time you add a new enumeration. Well, I'm something of a compulsive purchaser of programming books, and one evening I was idly flicking through the excellent Game Coding Complete when I came upon an extremely neat solution. You calculate a hash of a descriptive string, and use that as the event enumeration. For instance, if you have an event to set the gain of an amplifier, you calculate the enumeration as hash( "set_amplifier_gain" ). Store the string and enumeration in an object that gets passed around the system. Point your debugger at an event, and you see a clear text description of what it is. There's a bit of housekeeping to ensure that two strings don't accidentally generate the same hash value, but the approach is lightweight, and lets you arbitrarily add new events while only rebuilding applications that actually need to know about them.

So: two closely-spaced incidents. In one, I have a neat solution, and almost immediately stumble upon a matching problem. In the other, I have a trivial-but-irritating problem, and almost immediately stumble upon a neat answer. Both cases involved looking outside the scope of my everyday activities to add some tools to my grab-bag of solutions.

It's what Stephen Covey refers to as sharpening the saw, which is a great analogy, and resonates conveniently with the tools metaphor - we all have a bunch of tools at our disposal, and it behooves us to care for them. It also pays dividends to get new tools, upgrade old ones, or simply window-shop to check out what's available.

As the always-readable Rands wrote, "We see the world how we want. A carpenter sees all problems as a nail. I see problems as finite state machines." Well, amen to that, my brother. (Hint: a state machine may not always be the best answer, but it's almost always an answer.)

So: not exactly a profound revelation, just a gentle slap upside the head from fate, reminding me that it's always worth spending time learning new techniques, following interesting blogs and articles, and keeping a weather eye on seemingly unrelated spheres of interest. Even if the number of times you extract a true nugget is small, it's not vanishingly so, and the return on investment can be enormous.