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?

  • 12
    $\begingroup$ I think the best approach is the direct one: say that you really want to know the details, and you are comfortable with a mathematical discussion. It is often hard to know how to target the conversation if you don't know the other person's background. If this does not work and they continue being condescending, then I am afraid you need to find theorists who are not such jerks. I believe some exist.. $\endgroup$ – Sasho Nikolov Oct 22 '18 at 1:26
  • 7
    $\begingroup$ I agree with @SashoNikolov but from my experience, it depends less on the background of the person I am talking to than on the time I have to discuss. I would be reluctant to discuss technical details even with a theorist if we are having a short informal conversation over lunch. To really discuss details, I would rather fix an appointment to discuss this for an hour or two, which also give me some time to prepare material and think about how to present the problem. So maybe, you could ask your interlocutor if he has an hour to spare during the week to explain precisely the details. $\endgroup$ – holf Oct 22 '18 at 10:17
  • 7
    $\begingroup$ @holf makes a great point. Technical conversations need to happen in front of a board or a piece of paper. If you set up a meeting with the clearly stated goal to discuss some theoretical research, that clearly sends the message that you want to know the details and is more likely to be successful. $\endgroup$ – Sasho Nikolov Oct 22 '18 at 14:49
  • 2
    $\begingroup$ Both of these comments are excellent and should be made into answers. $\endgroup$ – Stella Biderman Oct 22 '18 at 22:26
  • 2
    $\begingroup$ @SashoNikolov's advice is very good. As a short-cut, you could also try saying "is this not just a special case of a Kan extension done internally in a Grothendieck topos?" Most things are. $\endgroup$ – Andrej Bauer Oct 23 '18 at 7:21

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.

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.


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".

  • 2
    $\begingroup$ This seems to contradict Neel's answer somewhat. As a "practitioner," sometimes I'm quite flexible about how we formalize the problem, and being able to talk about what we're actually trying to solve might lead to a more useful formalism down the line. $\endgroup$ – user219923 Oct 23 '18 at 23:55
  • $\begingroup$ Yes, but do try to a abstract away all of the unnecessary details. $\endgroup$ – Aryeh Oct 24 '18 at 6:59
  • $\begingroup$ "Yes, but do try to a abstract away all of the unnecessary details." I thought that's what theorists are good at. :p $\endgroup$ – Radu GRIGore Nov 8 '18 at 11:15
  • $\begingroup$ @RaduGRIGore We are, but our time is valuable and we prefer to work on an abstract problem, rather than listen to a lot of irrelevant details and waste time on doing the abstraction :) $\endgroup$ – Aryeh Nov 8 '18 at 11:55

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.