Leverage Existing Knowledge

Papert was careful to allow students to leverage existing knowledge in skills in their learning of new skills. We do this all the time, sometimes consciously, sometimes less so.

When faced with a sticky problem, there are a couple of classic approaches you’ll probably take. First, can you break the problem down into smaller, more manageable parts? This sort of functional decomposition is bread-and-butter to software developers: break things down into mind-size bites. The other very popular approach to take is to look for any similar problems you may have solved previously. Is this problem like some other? Can you use a similar solution or adapt the other solution to match this new problem?

Try mind-size bites.

George Pólya wrote a very influential book on concrete steps to problem solving that covers these and other classic techniques (How to Solve It: A New Aspect of Mathematical Method [PC85]; see the sidebar ​Problem Solving with George Pólya​ for a brief synopsis).

One of Pólya’s key bits of advice is to look for similarities to previous solutions: if you don’t know this, do you know how to solve something similar? Maybe the similarity is literal (this is just like a bug I saw last week), or maybe it’s metaphorical (this database works just like a fistful of water). In a similar manner, Papert’s students were able to leverage their existing, tacit knowledge of body mechanics, social interaction, language, and so on, to learn the turtle’s microworld and learn new programming skills.

But there’s a downside to looking for similarities.

You learn a new programming language relative to the concepts you knew from the last programming language. That’s why in years past we saw so much C++ code that looked like C, so much Java code that looked like C++, so much Ruby code that looked like Java, and so on. It’s a natural transition from one set of skills to the next.

The danger lies in not completing the transition and sticking with the hybridized approach instead of fully embracing the new skill. You need to unlearn just as much as you need to learn. Examples include moving from the horse and buggy to the automobile, from the typewriter to the computer, from procedural programming to object-oriented programming, and from single programs on the desktop to cloud computing. For each of these transitions, the new way was fundamentally different from the old way. And where they were different, you had to let go of the old way.

Another danger is that your notion of a “similar” previous problem may be completely wrong. For instance, when trying to learn a functional programming language, such as Erlang or Haskell, much of what you’ve previously learned about programming languages will just get in the way. They aren’t similar to traditional procedural languages in any way that’s helpful.

Failure lurks around every corner. And that’s a good thing, as we’ll see next.