Transmission of tacit knowledge: teaching what we don’t know that we know

In a couple of talks last year on the theme of network-enabled apprenticeship, I referred to an example of the transmission of tacit knowledge. What happened was that Jim Hugunin accidentally taught me a feature of the Python programming language — the use of the special underscore variable to store the value of the most recently evaluated expression — without ever realizing that I hadn’t known about it, or that his use of the idiom transferred it to me.

Now Chris Gemignani has taught me something else about Python in the same accidental and unconscious way. Last week I mentioned his geocoder for Excel. He’s also written a Python class that’s useful for batch geocoding, and when I found it today I was struck by this idiom:

print “location: %(latitude)s, %(longitude)s” % address

If you’re a non-programmer, here’s a bit of background. Most programming languages include some version of printf, a function that use a format string to control the interpolation of the values of variables into text. So in Python, for example, this statement…

print “location: %s, %s” % ( latitude, longitude )

…would interpolate the values of the variables named latitude and longitude into the format string “location: %s, %s” to produce an output like:

location: 42.933659, -72.278542

It’s quite likely, though, that those variables will be members of a data structure like this dictionary:

address = { ‘latitude’: 42.933659, ‘longitude’: -72.278542 }

In this case, your normal instinct will be to write:

print “location: %s, %s” % ( address[‘latitude’], address[‘longitude’] )

That works fine, but the alternative Chris revealed to me is better:

print “location: %(latitude)s, %(longitude)s” % address

Although I use Python extensively, I had never discovered this! It’s better in two ways. First, it’s more concise. Second, it associates the names of the variables directly with the percent markers in the format string. That’s not a big deal when there are only two variables to keep track of, but often there are more, and matching up the positions of the markers in the format string with the positions of their corresponding variables in the corresponding list is tedious and error prone.

Quite possibly none of this means anything to you, because you’re neither a programmer nor a Pythonista. Even so, I’ll argue that this principle of transmission of tacit knowledge is profound, and can apply to almost any discipline that’s subject to online narration.

There are all sorts of obvious reasons to narrate the work that we do. By doing so we build reputation, we attract like-minded collaborators, we draw constructive criticism, and we teach what we know.

Sometimes there’s also a non-obvious reason. It’s possible to teach what we don’t know that we know.

Posted in .

14 thoughts on “Transmission of tacit knowledge: teaching what we don’t know that we know

  1. Good story… but it seems to me that the term ‘tacit knowledge’ refers to knowledge that is ineffable, that is, cannot be expressed in words, and not to knowledge that the knower doesn’t know that he/she had (which would probably be better termed something like ‘unconscious knowledge’).

  2. Cool Python tricks. I find this applies a hundred-fold to emacs. Man, there is some spectacular stuff in there that I have learned by the grace of older hackers. And when kids watch me use it, they’re often like “how the hell did he just do that?” instead of solely noticing the actual code I’m writing.

  3. “probably be better termed something like ‘unconscious knowledge”

    Maybe so. I should go back and read Michael Polanyi’s _The Tacit Dimension_ which is where I first encountered this idea.

    He was fond of saying ‘we can know more than we can tell’ — which is, come to think of it, not quite the same as ‘we know more than we know that we know’.

  4. “I find this applies a hundred-fold to emacs.”

    Indeed. My ignorance of all that I could have been doing with emacs over the years is entirely due to the fact that I’ve never had many opportunities to look over the shoulder of an emacs adept.

    But then you can say the same about almost any application — Excel, for example. Which is why I’m so intrigued by what can happen when an expert user, like Chris Gemignani, gives us the opportunity to look over his shoulder.

  5. Jon,

    Great example. One thing that strikes me from your last 2 paragraphs is that perhaps your idea of transmission as a model of learning isn’t the most compatible with your ideas about building reputation, narrating work, and the underlying notion of participating in a community of practice around something (in this case, Python programming). When we talk about learning as transmission, the underlying model is that we hold all the knowledge we use in our own heads, and the way we acquire new knowledge is by having it passed – one person makes a little kernel of knowledge in their head public, and you receive it and integrate it into your own little in-head stash.

    But there is another, more broad, way to think about learning. The sociocultural or situative perspective on learning defines learning as the participation in a particular activity. This is distinct from the actual nugget-passing as a part of that participation, although that nugget-passing is a subset of learning-as-participation. By reframing learning in this way, it really opens us up to consider knowledge in ways that we haven’t before… for example, being able to find a voice in a conversation (in-person or online) about Python is certainly evidence of learning, but it doesn’t quite mesh with the transmission model.

    It seems to me that your participation in the discussion with Chris not only caused changes in your own in-head knowledge, but also caused you to write this piece, which serves now to bring us all into the periphery of participation in that community.

  6. “It seems to me that your participation in the discussion with Chris not only caused changes in your own in-head knowledge, but also caused you to write this piece, which serves now to bring us all into the periphery of participation in that community.”

    I guess that’s true, but the intermediary role I played here is not strictly necessary. Chris is a practitioner of a discipline in which there are a great many other, and less knowledgeable, practitioners. To the extent he is able to effectively demonstrate what he knows and can do, those who will benefit from looking over his shoulder will discover that they can do so, and they will learn from him.

    But it’s not just one-way transmission, if that’s what you’re suggesting. As I mentioned here — — it can be very much about participation. In that case, folks were both learning from Chris and at the same time teaching him.

  7. I enjoyed your article – I’d just like to share a few ideas from elsewhere that may add to what you wrote. There’s interesting stuff on programming in pairs, for example, leading to an overall improvement in the quality etc. of the code. Other experience points to the sum being greater than the parts at times in other groups (2 or more people). There also now seems to be a lot more exploration of the idea of immitation as part of learning, this includes other mamals and birds. The knowledge connection you’ve identified may only sometimes be fully realised by people sharing similar experiences, you may otherwise have simply learnt the new skill/kowledge, forgotten the how you gained it, not reflected upon the process of learning, nor recorded and published your experience and thinking to share with others. I’d hazard a guess that much of this additional thinking and communication is essential to ‘tacit knowledge’, and ‘knowledge’ in general – that may be what makes it ‘knowledge’ in the first place, rather than simply an improvement in your effectiveness as a python programmer.

  8. Jon,

    Another reason to use the %(name)s idiom is if you want to repeat a value in the string for some reason. It’s much easier to use the dictionary interpolation than count occurrences of %s and compare them to the contents of a tuple to make sure they match up.


  9. Jon,

    Nice demonstration of your point about tacit knowledge.

    That said, about the only virtue of printf format strings that I see is that their syntax derives from a common specification. In most languages, the format strings are passed to a core library unaltered, making the syntax invariant on a platform. This feature of python breaks that benefit. To me, it is not a good trade-off.

Leave a Reply