I have a lifelong passion for "getting to the bottom of things" -- searching for a deep, intuitive knowledge of a subject, from which all of the elaborations and detail follow. I love to render complex subjects simple, discarding vast tracts of detail as irrelevant to the problem at hand, and arriving at straightforward, elegant, and long-lasting solutions. In my career, I've been what I would call a "serial specialist." -- at each stage, focusing on a single area, but then moving on to something else after a period of time.

You could say I'm a right-brained thinker: While the end-results are logical, the process by which I arrive at them is chaotic and creative. I like to approach problems from many directions at once, skipping around rapidly in an effort to understand and "divide-and-conquer" the task at hand. I will often take two main tacks: what might work and what can't possibly work. I'm also known for my intuitive leaps, which can strand on-lookers.

Much of my time is spent in pure thought. To the outside observer, it looks like I'm wandering around aimlessly, perhaps picking up the odd object and carrying it around for a while and then putting it down in some strange place (ask my former office-mates, or my long-suffering wife); but people who've gotten to know me have come to recognize this state as one where I'm making active progress on something important. Inevitably, this stage ends (usually quickly), and I then enter a flurry of obvious activity -- writing code, asking questions, writing, talking, and so forth.

Much of what I do is make use of the common sense of one discipline to solve a problem in another. As one example, people familiar with computer hardware or numerical analysis will tell you that nearly all software makes extremely inefficient use of the hardware, running at perhaps 0.1% - 10% of optimum speed, but few programmers I've met are prepared to make use of this simple fact on those rare occasions where it's essential.

Over the years, I've come to recognize that often the best way to be smart is simply to not be stupid. Trying to be "clever" all of the time is one of the surest routes to failure.

I'm continually surprised at how frequently people attack the wrong problem. I, too, have been guilty of this on many occasions. Making sure that I'm solving "the real problem" is arguably the most challenging part of my work. In fact, what I often find is that an accurate and concise statement of the problem is all that is needed to make the solution obvious.