Technical Exodontia

One idiom in the programming/technical world that really should exist is a snappy term for "the act of painfully extracting information from someone who is insistent they have a problem with your system, but refuses to give you anything useful or diagnosable about said problem".

For example, here is a conversation I have had, in some form or another, with probably a dozen QA analysts over the last few years, including at a famous, multinational tech corporation:

QA: Your code isn't working! I'm trying to run it, and it's giving me an error message.
Me: ...
Me: ...
Me: ...
Me: ...
Me: Ok, fine. What does the error message say?
QA: Oh, hang on, I already closed it. Let me try and bring it up again.

(the conversation then passes through similar iterations as I try to figure out which actions led up to the error message, etc)

I don't mean to specifically pick on QA people, here, either¹. I've had variations on this same interaction with end users, project managers, fellow engineers, DevOps people, ... the whole spectrum. It seems no matter the level of technical savvy someone has, there's some configuration of personality traits that leads specific people to assume the person who they're asking to solve a problem should not need any actionable information on what the problem might be. This doesn't make a lot of sense to me, so I model these people internally as living in this constant state of low-level surprise that they are expected to provide useful information to others, perhaps mixed with a kind of irrational annoyance that the person asked to solve the problem can't just gather all relevant details through some kind of implausible remote diagnostic system and/or telepathy.

Anyway, I know this is a common problem because I keep griping about it with my engineer friends and everyone can add a story about it, usually from within the last week or so. And yet somehow, there's not any kind of clever name for the concept. I even read (well, skimmed) through a bunch of the jargon file and there wasn't one back in the Ancient Times² either. DWIM is somewhat close, in that it hints at the same general attitude (I shouldn't have to explain the problem in terms a machine/another person can understand!) but it's not about the actual endeavor of dragging adequate context out of a reluctant human.

This is shameful! Hacker culture has existed since at least the 1960s, and everything gets turned into some kind of goofy idiom. There's programmer shorthand for explaining a problem out loud to yourself in hopes of stumbling across missing insight, for working on annoying side problems that get in the way of your ultimate goal, for code that has been copied from somewhere else without anyone understanding how or why it works, even for fiddling with small objects at one's desk. And yet we don't have jargon for this!

"Pulling teeth" is kind of a generic English idiom for doing any task made difficult by another person's reluctance or inability to cooperate, but it doesn't have the specific technical meaning we're going for here. It does, however, carry the accurate spiritual connotation of trying to extract something from someone else who makes it difficult.

Anyway, the full Latin term for "pulling teeth" is apparently "exodontia". So, in lack of a better idea, I propose we call this action "Technical Exodontia" so we sound smart. An example usage would go something like:

Engineer 1: I spent 3 hours today fixing a problem that should have taken 20 minutes.
Engineer 2: What was it this time?
Engineer 1: Well, the project manager came to me with an "escalated issue". But between his taking ages to respond to my messages, and his inability to answer direct questions like "what inputs did you put into the form before it returned an error?", the technical exodontia took me all morning. And then the actual fix was just toggling a bool in a config file!
Engineer 2: Ah, yes. Many such cases.
Both: stare mournfully into their drinks