The Artima Developer Community
Sponsored Link

Weblogs Forum
Knowing and Learning

1 reply on 1 page. Most recent reply: Aug 17, 2003 3:34 PM by Alex Peake

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 1 reply on 1 page
Jim Waldo

Posts: 34
Nickname: waldo
Registered: Sep, 2002

Knowing and Learning (View in Weblogs)
Posted: Aug 17, 2003 12:07 PM
Reply to this message Reply
Summary
Some thoughts about knowing, learning, and software design, many of which were thought or written down while watching baseball.
Advertisement

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.


Alex Peake

Posts: 13
Nickname: alexpeake
Registered: Jul, 2003

Re: Knowing and Learning Posted: Aug 17, 2003 3:34 PM
Reply to this message Reply
Are you really just touching upon Bloom's Taxonomy of learning (http://www.odu.edu/educ/idt/eci_survey/Bloom.html )?

It is well known that many educational institutions stop short in the possible progression of learning. Once you have the taxonomy in mind, you can then readily test at all levels.

There follows the "short form":
Remember—recall of previously learned material. Knowledge represents the lowest level of learning outcomes in the cognitive domain. Knows common terms

Understand—ability to grasp the meaning of material. Understanding represents the lowest level of understanding. Understands facts & principles

Apply—ability to use learned material in new and concrete situations. This area requires a higher level of understanding than those under Understand. Applies concepts and principles to new situations

Analyze—the ability to break down material into its component parts so that its organizational structure may be understood. Analysis requires an understanding of both the content and the structural form of the material. Recognizes unstated assumptions

Synthesize—the ability to put parts together to form a new whole. Learning outcomes in this area stress creative behaviors, with major emphasis on the formulation of new patterns or structures. Writes a creative short story

Evaluate—the ability to judge the value of material (statement, business proposal, research report) for a given purpose, based on definite criteria. This area contains elements of all the other categories, plus conscious value judgments based on clearly defined criteria. Judges the logical consistency of written material

Flat View: This topic has 1 reply on 1 page
Topic: Introducing Dave Astels' Weblog Previous Topic   Next Topic Topic: Can Static and Dynamic Languages Live in Harmony?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us