Summary
Some thoughts about knowing, learning, and software design, many of which were thought or written down while watching baseball.

Knowing and Learning

One of the basic distinctions in epistemology (the philosophical study of knowledge, having to do both with what knowledge is and how we get it) is the distinction between knowing that and knowing how. These are very different kinds of knowing, and have to do with the question of where learning good design happens.

Knowing that is a relationship between a person and a proposition; this is the kind of knowing that has to do with content. So, for example, we can know that a string is a null-terminated array of characters in most C programs, but is an object in Java; we know that Bush is president (not all knowledge makes one happy) or that Pedro Martinez pitches for the Boston Red Sox. There is a lot of education that is centered around expanding the set of things that we know that; it is certainly the kind of thing that we are used to testing.

Knowing how is a different sort of thing; it is the kind of knowing that has to do with doing. We know (most of us) how to walk; this doesn't require that we learn the truth of a set of propositions. There are people who know the physics of the way a baseball spinning interacts with the air to change the nature of it's flight; this is a knowing that but is very different than knowing how to throw a curve ball. In at least this last case, society tends to reward those who know how more richly than those who know that. But such is not always the case. We all know how to do many things (healing a cut, recognize visual patterns) for which there is hardly any knowing that.

The two kinds of knowing are entwined in interesting ways, especially when it comes to education. When learning a new language, we begin by accumulating vocabulary, grammar rules, and idioms (all instances of knowing that) until, at some magic point, we know how to speak the language. I have been told by a number of lawyers that the point of law school is to get people to learn to think like lawyers; this is a knowing how (and, perhaps, some violation of natural law).

Another way of viewing this distinction is by contrasting the content of a field with the technique needed to be a practitioner in the field. Some fields (history, physics) have lots and lots of content that needs to be learned; others (law, mathematics, art, analytic philosophy) are almost all technique. Just as there are different ways of knowing, there are different ways of learning. To become an expert, you need to learn the content of your field (the learning that) but you also need to learn the techniques of your field (the learning how).

All of this has bearing on the question of how we go about training software engineers. Most of the academic teaching that goes on is centered around knowing thats, if for no other reason than that it is far easier to evaluate whether or not someone knows that something is the case. But most of what we value in the practitioners of software development (and design) has to do with knowing how, which is much harder to teach (at least in an academic environment). Knowing how to do something comes from repetition, practice, and being corrected as you proceed by someone who already knows how. It requires coaching rather than lecturing. Most of all, it takes time and doing it wrong.

Returning to the subject of my last entry, I think that this is the reason a lot of training in design happens by serving an apprenticeship with a master designer. Apprenticeships have always about learning how to do something rather than acquiring a set of knowledge (although knowledge is certainly acquired along the way). The process of learning by doing under the eye of an experienced practitioner is a great way of learning how, just as the standard classroom is a good way of conveying learning that to a large group. But we should recognize that the two learning techniques are optimized for different cases.

This is also why, in the corporate world, time spent in graduate school is often equated with time spent on the job. For at least the first few years of each, what is being served is an apprenticeship. In the case of graduate school, it is a professor who is the master; in the case of a job, it is the technical lead of the project. The quality of the training obtained in either situation is heavily dependent on the skills of the person to whom one apprentices, but in both cases much of what is learned is not facts about the subject of computer science but technique that allows one to be a system designer.

What I find surprising about all of this is that we almost never acknowledge this aspect of the training needed for our profession. In this we differ from many other professions. Medical doctors have to serve internships and residences (which are, after all, just fancy names for an apprenticeship). Lawyers are first associates before they become full members of a firm. But often students who have finished a degree in computer science think that their training is done when they finish school. This lack of Socratic wisdom, this failure of knowing what they don't know, often stands in the way of the rest of their training, which begins when school ends.

For the best in our field, the training never ends. Serving an apprenticeship may make one a journeyman, and further experience may make one a master. But the best of the masters are constantly training themselves, either with others who have higher levels of skills, or those who have different kinds of skills (for one of the realizations one gets is that there are many different approaches to the problems of design, so there are always new ones to learn), or by learning from those who are learning from them. Being a good designer requires learning all the time; it is one of the things that makes design both difficult and rewarding.

Talk Back!

Have an opinion? Readers have already posted 1 comment about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.