How to talk about theory

Question

I realize this might be a contentious question, but this seemed like the right place to ask. Please redirect me if not.

The background is that I am a "practitioner" (PhD student, I don't study CS theory) but I have a reasonable foundation in undergraduate algorithms and math. Nevertheless, discussions with theorists are usually very surface-level, as if they're afraid to use mathematical terms with me in case I get scared. In reality, I'm perfectly comfortable with and interested in theory, but I'm just not used to discussing it so I probably don't always use terms that would flag me as "theorist". I find that the direct approach ("please tell me the details") doesn't always work, particularly if the theorist in question has assumed a condescending tone that sets a high bar for expertise (this happens often).

As theorists, if you filter people in this way, do you have recommendations for how a practitioner can avoid being "flagged" by your filter?

Answer 1

You may be working with rude elitists, but from my experience, being reluctant to explain technical details depends more on the context than on the person I am talking to. I would usually avoid giving technical details of a proof/algorithm over lunch or in the corridor even if my interlocutor were Alan Turing himself. The reason is that details heavily depend on the choice of notations and on hand-crafted concepts introduced to smooth a claim. Also, because everyone understands things differently and I do not have a generic way to explain a concept, I always have to adapt to my interlocutor (that is why giving technical details in a research presentation is so hard by the way).

One exception is if my interlocutor has worked closely with me on this kind of problem and then, I know that we can use this common gibberish that only we understand because we grow into it together after several white board sessions (or before an urgent deadline).

Another exception is if after giving a crude overall scheme of the proof without details, my interlocutor asks a precise question showing he has seen a particular hard part of the proof that I have been intentionally hiding from him in order to simplify the presentation. In that case, we would naturally open the Pandora box and go together into the heart of the proof, layer by layer... and usually end up on a white board because at some point, we again need this common gibberish that only fit us and this problem.

There are several morals with my already too long story:

• Do not depreciate yourself because you are not actively working in theoretical computer science. Most people will not care about your precise background as long as you show that you are curious about their work.
• When people are vague about a proof/concept, stay alert and try to guide the conversation by asking a precise question showing your understanding and thus helping your interlocutor to choose which part of the proof he should develop first. This is obviously quite hard and unpredictable because you may not be able to give relevant comments on the go (this happens to everyone even to "theorists"), but if you manage it, then you will likely end up with a very enlightening discussion.
• Even "theorists" need time to reload the details of a proof in their head before being able to clearly explain it. Make an appointment by explicitly asking that you are interested in the technical details of X. This will allow for time for your interlocutor and you to prepare, and will ease the discussion. Make sure to have a white board or a piece of paper during the discussion so that you can really go into details.

Answer 2

Speaking as a theorist who has occasionally collaborated with systems researchers, mathematical details are usually the very last thing I want to talk about!

It's really, really, easy to formalize the wrong thing, and in addition to being a huge waste of time, it's really dispiriting. Mathematics is a needle, not a hammer, and each jab of the needle is very expensive. If I'm talking to a systems researcher about a prospective collaboration, before getting to any high-church mathematical ceremony, I want to know:

1. What is the problem he or she is trying to solve, and why does anyone care?
2. What are the techniques they are currently using to attack this problem?
3. What are the plausible alternative approaches?
4. What are the constraints on the solution?
5. How did those constraints lead to the choices made?

Note that these are mostly the same things any another prospective collaborator would want to know, and the reason is that in order to figure out a productive line of attack (mathematical or otherwise) you have to have a clear sense of what is important to keep in a model and what is inessential.

E.g., a systems researcher collaborating with an HCI researcher will have to go through the same process before the HCI person could design a useful experimental protocol for doing a user study -- no one would expect that a worthwhile experiment could be conducted without a good understanding of the problem. You should have the same expectation for mathematical modeling!

Furthermore, it's almost always the case that even with these answers, the first go-round is wrong, because a lot of the most important factors usually live in the good taste and engineering sense of the person I'm talking to. Teaching and learning good aesthetics is hard, but that's also why such collaborations are worthwhile.

Answer 3

I really liked Neel's answer, and it inspired me to share some of my experience as a theorist occasionally collaborating with more applied people. One of the most difficult and frustrating stages of the collaboration is finding a common language -- so that the problem can be formalized correctly. In my experience, when posing a problem for a theorist to solve, people tend to give too many irrelevant details. For example, if we're trying to predict a time series, is it really necessary to spend 5 minutes telling me that these financial transactions are subject to such-and-such regulations which you want to leverage in such-and-such ways?

My concrete suggestion for talking to theorists: Try to strip away all of the unnecessary details. If trying to optimize a delivery route, talk about points and distances (as opposed to telling me the specific addresses). When talking about data, say right away what its type is: strings, numerical vectors, images (in what format?). Is it labeled or unlabeled? If the former, what's the "type" of the labels (binary, multiclass, multilabel, text annotation, real-valued)?

Keeping track of the "type" of object you're dealing with (set, vector, string, etc) is incredibly useful and can avoid a lot of confusion. It's how I instruct the students in my intro classes to approach every object they encounter, and it's also how I would encourage everyone to talk to theorists (even other theorists!). If you start a question with "I have a set of $d$-dimensional vectors", I guarantee you'll get a better response than with "I need to learn to tell cats from dogs".