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.