What is Programming Wisdom?

This is the first post of my new BlogBook, Programming Wisdom.

This initial post starts off by discussing exactly what I mean by "wisdom" in the context of programming. Non-programmers may still be interested as it is more about wisdom than programming.

Wisdom is now one of those Old English words that you're probably only likely to encounter in a church nowadays, like Atonement or Reconciliation. In the era of exponentially-exploding knowledge, wisdom has been just plain crowded out.

For a long time, my favorite definition of wisdom was: "Knowledge is the knowing of a fact; wisdom is understanding how to apply the knowledge." I think there's still some truth to that, but I've come to prefer this formulation:

Knowledge is when you know some fact about something.

Wisdom is when you have a sense of the whole system, and can take actions based on the whole of the system, not just a part.

I think here are two basic kinds of wisdom:

• Received wisdom: Hard and fast rules generalizations, often passed down the generations and now phrased in absolutes, because after every person passing along the wisdom is done simplifying and distorting it, like in the classic Telephone game, what's left is incomprehensible and worthless. This is best demonstrated by the well-known joke/parable about the mother who cut of the end of her pot roast for reasons unknown; what started as a perfectly reasonable practice was brittle and useless "received wisdom" within two generations.
• Learned wisdom: The wisdom you have put together yourself over the years, from your own experiences.

Every generation of recorded history has had to re-examine its received wisdom, and replace some of it with learned wisdom. This is both a personal process and a societal process, especially important in a democratic government where "prevailing wisdom" can have an impact on the actions of the society.

Learned wisdom can not be taught, because it is too complicated; the full totality of a system of understanding can not be expressed in words. The wisest solution for any given problem changes radically depending upon every aspect of the specific situation. Everything from the smallest technical consideration to the largest political consideration matters.

Received wisdom may be inferior to true wisdom, but it is also simpler, and there are times when that is enough. One of the better ways to conceptualize parenting is providing the child with a good enough "received wisdom" scaffolding so that they can survive long enough to develop their own true wisdom.

There are many things like this in life, including life as a whole. You can read all about football strategy all you want, but until you're out there on the field you can't understand the full depth of the situation, and once you are out there, you realize that the theory only scratches the surface. You can't become a master chess player by reading about chess.

It is easy to conclude from this that reading about chess or football is a waste of time, but that's untrue. What can be done for wisdom is to sensitize the student to the structure of the problems they will encounter, to offer them initial tools to approach the problem with, and (ideally) to encourage the student to eventually work out their own understanding of the topic, and fly free. You may obtain mastery without ever learning the theory, but done properly, you'll attain mastery faster if you bootstrap off of the theory. Most likely, you'll learn it better in the end too, and the theory can provide you with new words and concepts you can use to communicate with other people who share your understanding of the theory.

The purpose of this book is to so sensitize you, to speed wisdom and to a lesser degree, to offer you some initial scaffolding you can build around. I consider the latter a lesser goal because you can find many places online and in the book store that could help with the scaffolding; it is the other ideas I chose to write about here because I do not know of a single place to find them. Some received wisdom is inevitable, because without discussing real problems this already-abstract work would become too abstract to be useful. I also hope to help you avoid the common error of prematurely mistaking some particular bit of received wisdom or dogma as Absolute Truth; you must learn to make your own judgments.

Much of what I say here is said elsewhere of course, but I believe the consistency with which I apply my unifying principle (about which more later) may be unique. Some of the perspectives I have here are also at the very least unusual and possibly unique among the set of people who write about programming. I am directly targeting programmers first starting out on their way, perhaps a sophomore or junior in college, or someone who has been programming for a year or two. Those whom have been actively working on building their own wisdom will probably find somewhat less value here.

In fact, they will certainly find things they disagree with; I'd even go so far as to call it a necessary (but not sufficient) condition for being wise. One of the characteristics of the rich problem space that so many things in life present is that due to our different experiences and perspectives, no two of us ever come to the exact same understanding. But even though you will eventually end up disagreeing with me, you will hopefully develop faster for having been exposed to the right kind of wrong idea.