I use “tacit knowledge” a few places on this site but I mean something else than what the main stream means. I mean something that we know we know, but that we overlook. (Better: knowledge that we rely on that we do not realize that we are relying on) When an expert C++ programmer reads and modifies a C++ program, he employs many small pieces of knowledge unconsciously, any of which he could explain to a colleague of lesser expertise who asks the right question. This is good for it enables the expert to morph complex software effectively and also to teach this talent to colleagues. The expert is usually unaware of the magnitude of the body of knowledge that he employes. An unfortunate side effect is that such experts may tend to think experts of other disciplines as dumb. The feeling, naturally, is mutual.

Many programming environments, such as C++, Java, Unix, have their practitioners who know a great deal and think that their environment are very easy to use. It is easy for them because of what they know, but they underestimate the cost to others learning what they know.

Several anecdotes referenced in the above article are used to illustrate tacit knowledge. Another is a story of an attempt to duplicate a factory that manufactured light bulbs. The original was in Germany and the duplicate was to be in Hungary. Careful descriptions were made by the operators of the original plant. These were applied in the new plant but much additional information was needed and received only as problems arose in early production. The operators of the original plant did not know what they knew, in some sense.

When Intel builds a new chip plant they are almost superstitious. They admit that they don’t know which plant features are significant. They arrange the plants with the same layout and paint the walls the same colors.

I quote David Pogue: I propose that the ‘product manager’ indeed relied on deep internal knowledge of the various system components and could not imagine some other state of mind. This seems like an outrageous claim for someone whose official job it is to understand the knowledge base of his customers, but is there any other explanation for this phenomenon? There are two sorts of knowledge which should be discriminated here: It is the second category of knowledge that is often tacit and overlooked. It is not in the user’s ken because he has never heard of it. It is not in the product manager’s ken because he cannot remember not knowing it and cannot imagine a knowledge base without such knowledge. The product manager does not even know the name of the feature perhaps; in the new interface it is a mere gesture to achieve some effect, just as riding a bicycle involves motions for which the rider has no name. The programmer of the application probably has a name for the feature or the programmer of a module used by the application. This phenomenon is not limited to ‘management types’!