Responding to an idea by saying you don't understand when you actually do.
There are actually two versions of this. In the first, you are trying to denigrate or avoid the idea. This is described in ConversationalChaff.
In the second version, you are trying to force the other member of the conversation to expand on their explanation of the idea [VisitorFromMars]. I find this form useful when I think I understand the idea, but am afraid that I might be rushing to a misunderstanding. Instead of going off on a tangent talking past each other with two different mental models of the idea, it can be more efficient to make sure that we are really on the same page first. There are certainly more polite ways to ask for further explanation, but I find that people tend to just repeat the same description with minor variants in this case. If you say, "I'm so stupid that I have no idea what you are talking about", then I can often force them to describe the idea from a different viewpoint. If this second viewpoint matches your mental model, then the odds are better that you are really on the same wavelength. -- MikeGarrity
Like when I ask "Could you say that again, but with different words?".
This sounds like the Socratic method ... (EditHint: Is there already a page that explains educational techniques? Are educational techniques even on-topic for Ward's Wiki? - They should be - you often need them with customers, and customers with you )
When using the second version (the "positive form") in a discussion, it is important to make it clear that you are looking for additional information or alternative descriptions, and not trying to make the other person look like an idiot. And whenever the confusion is cleared up, it is good form to refactor the discussion to remove the wilful misunderstanding. (And PullUpTheLadder? after you?)
Wilful misunderstanding is an important technique to use when reviewing a specification or a design, or when writing UnitTests. Do your best to simulate a "dumb computer" that will do exactly what it is told, but without regard for what the desired behavior is. Draw inspiration from those fabled evil genies who grant wishes but who twist the meaning of the wishers' words to do them harm.
For DefensiveProgramming, I would go further and say that it is essential to be able to do this, at the same time as you question the assumptions or preconditions for the code in question. WhatYouGetIsWhatYouAskFor?, it's the UnixWay.
Much of programming is about making generalizations from an assortment of cases. When you have code to handle the general case (or worse, if you should but don't) then you may need to imagine and examine the CornerCases? of that generalization. -- MatthewAstley
When testing a piece of code, it's useful to "lie" to the program to make sure it handles user typos properly.