The Tacit Dimension

Christian Ekrem wrote up "The Tacit Dimension - Why Your Best Engineers Can't Tell You What They Know," and it's a good, informative essay, but he's overapplying a thesis.

The heart of the essay is chemist Michael Polanyi's 1966 assertion: "We can know more than we can tell." It's a derivation taken from experience: how does one have gradient expertise? His examples are apt: a surgeon feels the right pressure, a researcher understands the shape of promising work before it's analyzed. In my own experience, a melody or rhythm sounds right or wrong, or a radio control plane is flying properly or, more often in my hands, not.

This kind of tacit knowledge is difficult to communicate: it must be experienced, over and over again, until it's ingrained. Ekrem makes a good point about how AI cannot hold tacit knowledge: it has no mode of experience, so it can only look at the data and say "this is what people have written down as correct," and that creates a sort of isolated knowledge that is related to the real world but is not the same thing.

This is important. But it's also a diagnostic, and that's where I have a gentle disagreement with Mr. Ekrem: there is tacit knowledge, but he's overfitting. He uses examples like "We never throw exceptions across this module boundary," and an auth system designed for a specific failure mode that the docs don't mention and that nobody's encountered, thanks to the design.

He says these are not problems "more training or better models can fix."

... but they are.

There are certainly problems more training or better models can fix - an AI does have to work with an articulated body of knowledge, and people don't always articulate the right things, so what the AI has to work with tends to be incomplete and inexperienced in the real world¹. But most of his examples have the same problem: they assume that because something hasn't been written down, it cannot be written down. The following example is great, and it's great because I've seen the same thing in production myself, although with rather different details:

A guy I worked with a while back, much smarter than me, once spent an entire afternoon refusing to merge a PR that, on paper, was correct. The change worked. The tests passed. CI was green. He couldn’t articulate what was wrong. He kept saying “I just don’t believe this code.”

Eventually he asked the author to walk him through the reasoning, line by line, out loud. Maybe forty minutes in, the author said something offhand: “well, this assumes the queue is FIFO, but I think that’s safe.” It wasn’t safe. The queue was FIFO in development and best-effort-FIFO in production, and the difference was buried in a runbook nobody had looked at in two years. My colleague had smelled it from the diff. He couldn’t explain why up front, but luckily his persistence (and frankly his good reputation as someone one should listen to when it comes to software engineering) made him too hard to dismiss. He just “didn’t believe the code”.

That afternoon cost a few hours of two engineers’ time. It probably saved a months-long incident.

This is wonderful. But he says "this kind of work is impossible for an AI."

My thought: really? Look at the problem: there were tests! They worked! But production did not match the tests - it usually did, perhaps, maybe almost always, but the production environment was not the same. Those tests were green, but they were not good tests because they didn't match the production system; somewhere, somehow, there was a divergence and nobody cared. That junior dev created an articulation, something that can be known, something that can be removed from the set of tacit knowledge.

The junior exposed a bug in the ontology: the ontology said "This is a FIFO queue," but reality said "It's usually FIFO," and that is not an insignificant difference.

This is not to diminish the role of the senior here: he had tacit knowledge, and that's something that's worth cherishing - he did have knowledge, and did share it. This is a conversion: it's a bug in the system of knowledge, and the solution was to fix the FIFO-ish definition so the articulation is accurate.

Left uncorrected, that's a real negative - because it means the valuable senior is now a failure point. If that engineer leaves, the knowledge leaves with them. That project can fail without them, and that's a good reason to try to encode and articulate as much institutional knowledge as possible, with or without AIs. That queue being FIFO-ish should have been core knowledge and wasn't.

There's no doubt in my mind whatsoever that tacit knowledge exists, and is valuable; it's what you get from practice. But I'd also suggest that readers ask themselves "why" on a regular basis - and an articulation of why is something that can be made explicit, not tacit.

A feel for pressure along a vein lives in both dimensions at once. What that pressure here means, and what to do about it, is teachable and explicit. How much pressure, judged through your own hands, is the part that stays tacit.

And knowing the difference - which knowledge is irreducibly tacit and which is just unsaid - is the difference between a great engineer and a good one. A great engineer sees that line and makes as much knowledge explicit as he or she can, because that creates others who grok, who wholly understand.

Ekrem makes that point clearly: he suggests that people who take Polanyi seriously do these four things:

• Re-elevate apprenticeship. (Show, don't tell!)
• Distinguish articulated from tacit work. (His essay fails to do this itself in a lot of ways, which is ironic and gently observed.)
• Resist the fluency mask. (Don't expect the articulations from an AI to understand your code, if you know there are tacit reasonings involved.)
• Pay seniors to teach, not just to ship. (Here, he's telling organizations to use their experience and value it, as opposed to what we see a lot now, where bean counters seem to think that every bean has the same value, so get rid of the expensive ones that actually have nutrition.)

He closes his essay with these words, and I think they're pretty well-written, even if I think he overclassifies information himself:

The Articulation Era will pass — these things always do. When it does, the developers who quietly kept the tacit dimension alive, by mentoring and reviewing and refusing to outsource the work that mattered, will be the ones the next generation of teams desperately needs.

We can know more than we can tell. Make sure your team still has people who know.