The Power of Analogy

Today after many years of managing teams, I realized why I suck at programming (something I used to be extremely adept at). I lost the power of software analogies. At my peak, I had written so many lines of code, there was always something I could use, morph or base a new design on. The modern software developer will call it design patterns. When you understand a problem and able to apply an appropriate solution template, you can copy, adapt or write the code extremely quickly, efficiently and with less bugs. Learning all the design patterns is only half the solution, knowing how to apply them and when to customize is the other half. Problem is, while I didn't lose the ability for good design, clean coding and fast debugging (at least I hope not), I lost the bag of tricks, forgot the syntax and didn't have any personal libraries to rely upon. On the plus side, life has gotten so much easier than the days of Kernighan and Richie when you pretty much had to roll your own quicksorts and hashtables or having to program at the socket level just to make an http call. I do feel like the old man on the snowboard, having loads of fun but probably a dangerous hazard for others.

Analogies, like design patterns, can be learnt but never appreciated unless you've experienced them yourself because like so many things, you probably have do it the wrong way a dozen times before figuring out how to do it right. But age becomes the crucible for experiences and from them you can draw analogies. As an entrepreneur, I'm often challenged by my peers and investors who tell me what I'm about to embark on I haven't done before. Maybe we should find someone who has. My answer is that if I've done it before, I probably don't want to do it again and if someone has done it before, maybe we don't want to do it anyway. The genius of the inventor is not because he has travelled the same path repeatedly or sat under a tree waiting for the apple to fall. It is because through repeated experimentation and iteration, he manages to cross the chasm between two seemingly disjoint ideas in time and space. It is about astuteness in spotting trends, wisdom in finding analogies and creativity in making extensions and deviations in thought. It is no different whether you are trying to solve a software model or a business model.

Note to self. Of course, analogies do sometimes lull us in the false sense of superiority. Maybe this time it really is different... So a healthy dose of humility is never out of vogue.

Here's a conundrum of the day (not disimilar to the problem of the dining philosophers). I read an article in which a successful leader said one of his maxims was to surround himself with people smarter than he was. It is something I have always subscribed to (in my case...not a hard objective to achieve!). However, my current little adventure consists of two people writing code, my colleague and me. If we both believed in that philosphy and base our eventual success on it, only one of us can succeed (if we exclude the possibility that we are equally smart or equally dumb!) What should we do?...thinking out the box, maybe we should hire someone else who is smarter than both of us????