Seeking Wisdom

One of the first topics in the biblical book of Proverbs is the truth that fools despise instruction, whereas the wise seek it. The same fact comes later in the form of “do not cast your perls before swine.”

It is obviously good to search for wisdom and understanding.  We all want to be ise and none of us would intentionally choose to be (or remain) a fool. So where are the storehouses of programming wisdom? Where is this well?

The first and most obvious application is that developers need to stay current. In looking into new technologies, languages, techniques, and methods we are looking to our own futures.  It may be that a lot of this new tech will not pan out, but a lot of it will teach us something new on its way through.  All we know  for certain is that the future doesn’t stay “the future” very long. It is easier
to keep up than to catch up.

Another obvious application is that we should learn from each other.  Many of us find we learn faster with either a “learning partner” or a skilled teacher. We read blogs and articles and books, so we should not refuse to learn from each other in a face-to-face.  We should learn from both the old programmer and the new graduate.  Both may have things to teach us.

In the agile world, we find the practice of pair programming.  What is this other than sharing wisdom?

But let’s look at the non-social side of this.  Let’s seek wisdom and knowledge in the code we read as well.   This comes in two forms.  The first is the wisdom that the author put into the code.  Some things seem like foolishness at first, until we realize that the author understood things we did not.  The strangeness of the code can be due to either the original author’s ignorance or the current reader’s.

Also, we find that there are tools whose sole purpose is to search our code for typical errors.  Tools like “lint” for C will draw our attention to errors in formatting our printf statement, or uninitialized variables, or unneeded includes.  Similar tools exist for Python and probably most other programming languages. It is wise to seek out advice this way.

In another application yet, we have learned to “listen to the code” and determine what “it wants” to be. In the course of coding and refactoring we  often find that the code seems to naturally gravitate to a given state. Any single, atomic operation tends to “want” to be a function.  Related functions seem to “want” to be a class. The data they operate on also seems to “want” to belong in that class.  We then find that some operations don’t really “want” to be there, they have some other place they “want” to live.  We refactor and shuffle responsibilities until the code seems “satisfied”.

So we can listen to other people, listen to their code, listen to the tools they’ve built, and listen to the code we write.  If we seek wisdom in these ways, surely we will acquire some of it.


About this entry