Questions I hate to hear

I'm not sure how it is in other cultures. In American culture, there are a couple of standard questions that are typically asked upon meeting someone for the first time.
"Where are you from?" - I'm sure I'm not the only military brat who hates hearing that question. My usual answer is "All over", which unfailingly provokes puzzled looks. "My father was in the Air Force" usually convinces most people that they know what I'm talking about. Inevitably, I end up rattling off the entire journey: Rantoul, Illinois; Rubidoux, California; Riverside, California; Brookline, Massachusetts; Onville, France; Bayonville, France; another town in France; Toul-Rosieres AFB, France; Charleston, South Carolina (three different domiciles); Riverside, California; Phoenix, Arizona; Eugene, Oregon; Olympia, Washington; Burnsville, Minnesota; Costa Mesa, California; Santa Ana, California; Salt Lake City, Utah; El Segundo, California; Burnsville, Minnesota; and finally, Eagan, Minnesota. And I know there are people who have lived in as many places, or more. And I wonder if for them, as it is for me, that that is a question that usually goes unasked. But most of the time the people asking that question look at me like I'm from another planet, or an alternate universe.

The other question that I find difficult is "What do you do?".
The short answer is "I write operating systems code for mainframe computers. My area of expertise is system initialization and memory management."
This usually puts an immediate end to this portion of the conversation. Most people have only the vaguest idea of what a mainframe is, and an even vaguer idea of what an operating system is. And I've found that even people who nominally work in my field really have no idea what I do.
One friend, who worked with me at Unisys and then became the support manager at several startups, was kind enough to tell me what one of my notable talents is. He informed me that I was the best diagnostician/debugger he'd ever encountered (I suspect he was overly impressed from watching me bust a dump of the operating system over the phone). But he is right, I'm certainly one of the best in my area of figuring out what's broken, and how to fix it.
But I think that what I really do is pattern matching. Given a set of symptoms, and materials (dumps, log entries, what have you), I can usually detect the underlying pattern that allows me to identify the bad code, or the bad design, and come up with a solution. At one point in time, my company was trying to come up with an Artificial Intelligence program that would be able to bust dumps of the operating system. So they sent the developers of the program around to all of the best dump busters, and asked "What do you do when you bust a dump?" The most common answer was "I start at the back of the dump, and I page forward, looking at the dump, noticing things that aren't right. Eventually, all the things that aren't right coalesce into a conviction of what the problem is, and what piece of code caused the problem. And then you just have to read the code to find the bits that you're looking for." I don't think the developers found this answer particularly useful.
And I think I do something similar when I'm developing software - I push ideas and code fragments around, until the structure of the code matches the pattern I have envisioned that will yield the desired result.
And I know I do something similar outside of work. I look at things, and listen to things, and unconsciously fit my observations into patterns. This works well enough, most of the time. But every so often, something gets a little off. I start feeling like I'm receiving mixed messages from people. I'm pretty sure most people aren't sending me mixed messages - but I receive them, nonetheless. And that's not much fun. It's a whole lot easier to deal with co-workers and friends when you aren't constantly asking yourself "What did so-and-so mean when they said such-and-such?" Eventually, this passes, and I return to what passes for normalcy for me.