If I could choose one dead dude to pair programmer with, it would have to be Descartes.  Descartes' first work, Rules for the Direction of our Native Intelligence, set forth most of the knowledge necessary to take on the most arduous challenges that we encounter while designing and developing software systems.

In the twilight of the 21st century (aka 1999 or so), almost everything a Microsoft web-developer needed to know consisted of HTML & VBScript, some ADO.NET & SQL, and a bit of JavaScript.  Contrast this to my most recent project's tool suite consisting of a dozen different utilities and frameworks ranging from ORM solutions to JavaScript libraries along with a variety of helpers for AJAX, AOP, logging, IoC, GUI elements, etc.  With the speed in which the technologies in our industry change, it's now more important for someone to know how to solve problems rather than to know how to use a specific tool or framework.

Getting back to Descartes, he proposed a system for solving problems which became the basis for modern, scientific method.  His advice is still apropos when trying to solve vexing software problems...

"The whole method consists entirely in the ordering and arranging of the objects on which we must concentrate our mind's eye if we are to discover some truth.  We shall be following this method exactly if we first reduce complicated and obscure propositions step by step to simple ones, and then, starting with the intuition of the simplest ones of all, try to ascend through  the same steps to a knowledge of all the rest.

In order to distinguish the simplest things from those that are complicated and to set them out in an orderly manner, we should attend to what is most simple in each series of things in which we have directly deduced some truths from others, and should observe how all the rest are more, or less, or equally removed from the simplest."

Descartes' point is that if we're trying to solve a problem, we first need to start with something that we can wholly understand.  This is fully applicable when trying to translate domain language into a working domain model or when trying to fix an elusive software bug or when learning a new technology.  We often try to "eat the whole cake" at once leading to frustration and confounded efforts.  I often find a solution to a problem only after taking the time to remove extraneous details to zero in on the simplest elements that I can fully understand.  Only then can I begin taking steps "up" the chain towards the bigger picture and bringing the solution to light.

Now if I could choose two dead dudes to pair program with, the other would have to be George Pólya.  Dr. Pólya wrote a seminal piece of work entitled How to Solve It:  A New Aspect of Mathematical Method.  Within this treatise on problem solving, Pólya puts forth basics steps for solving a problem, consisting of:  understanding the problem, devising a plan, carrying out the plan, and reviewing/extending this plan.  More fully, Pólya suggested that we consider the following when attempting to solve a problem.

"What is the unknown?  What are the data?  What is the condition?

Separate the various parts of the condition.  Find the connection between the data and the unknown.  Look at the unknown!  And try to think of a familiar problem having the same or a similar unknown.

Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary?  Could you derive something useful from the data?  Could you think of other data appropriate to determine the unknown?  Could you change the unknown, or the data, or both if necessary, so that the new unknown and the new data are nearer to each other?

Did you use all the data?  Did you use the whole condition?"

As software systems become more complicated and our suite of tools more diverse, we must place increasing attention on best practices for effectively solving problems.  Fortunately for us, centuries of thinkers have laid down the groundwork for us to do just that...even if we can't pair program with them in person.

Billy McCafferty