When I did my PhD I hated it when (most) people asked about my research. It's not because I wasn't interested, it's because I'm really interested and was (still am) bad at giving concise summaries, so I felt like people who really didn't care and wouldn't listen to the answer were asking me to embark on a long explanation that required a bunch of preamble etc, just in order to make conversation. Anyway, I feel largel…
> bad at giving concise summaries This seems like something you could work on instead of implying it's other people's fault for asking you about a topic that they don't know they aren't interested in yet. If you have a punchy 20 second description, and then ask what they do, you'll have pivoted away unless they want to bring it back.
Though when doing a PhD, it's a worthy goal to be able do give a quick description. It also forces you to think about the goal / meaning of your work. Some topics are more easily summarized, but still.
We do science for people, it's only fair to be able to present them your work more or less roughly.
I had something for people not into computers, like: "I work on a method to find and understand computer bugs quicker and better." (Familiar with bugs? you don't like them? So you know it's useful!)
And then I could develop for the curious.
"Programs are written with code that tells the computer what to do, step by step. Like a cooking recipe. There are tools to see programs do things step by step so you can notice some step is wrong. On big programs this gets tedious. My approach helps starting this step by step investigation closer to the problematic step."
If still curious: "How? There's another method that looks at the step that looks at these steps and check they are correct with respect to some given rule. For instance, if you have a bag of objects, no step should try to remove an object if the bag is empty. This technique usually tells you something is wrong but does not tell you why it happen. I combine the first method with the second one: when some rule is broken, you are left exploring the program step by step at the point the rule broke, which is way better than doing it from the beginning". And go further / present the caveats if I feel whoever is listening is still curious.
For the people who already actually interacted with some code, I would also drop the technical words that are probably familiar to them. If you don't know whether they already actually know some stuff, they usually say the technical words themselves, to clarify.
For people who asked politely, they would receive the one sentence summary but often they want to know more if you piqued their curiosity. I had something like a progressive image of the thing that gets more and more precise to stop at the right time.
By the way you probably started skipping paragraphs in my comment at the point yours was satisfied. I made several paragraphs to allow you to do so.