One of the things I like to think about while watching research talks is whether the work faces inward or outward. Inward facing research is mostly concerned with itself. A paper that uses most of its length to prove a theorem would be an example, as would a paper about a new operating system that is mainly about the optimizations that permit the system to perform well. Outward facing research is less self-aware, it is more about how the piece of work fits into the world. For example, our mathematical paper could be made to face outwards by putting the proof into an appendix and instead discussing uses of the new result, or how it relates to previous work. The OS paper could demonstrate how users and applications will benefit from the new abstractions. Computer science tends to produce a mix of outward and inward facing research.
Next let’s turn to the question of whether a given paper or presentation should be inward or outward facing. This is subjective and contextual so we’ll do it using examples. First, the mathematical paper. If the proof is the central result and it gives us new insights into the problem, then of course all is as it should be. Similarly, if the operating system’s use case is obvious but the optimizations are not, and if performance is the critical concern, then again no problem. On the other hand, researchers have a tendency to face inward even when this is not justified. This is natural: we know more about our research’s internal workings than anyone else, we find it fascinating (or else we wouldn’t be doing it), we invent some new terminology and notation that we like and want to show off, etc. — in short, we get caught up in the internal issues that we spend most of our time thinking about. It becomes easy to lose track of which of these issues other people need to know about and which ones should have stayed in our research notebooks. Let’s say that we’re working on a new kind of higher-order term conflict analysis (just making this up, no offense to that community if it exists). One way to structure a paper about it would be to discuss the twists and turns we took while doing the work, to perform a detailed comparison of the five variants of the conflict analysis algorithm that we created, and to provide a proof that the analysis is sound. Alternatively, if the running time of the analysis isn’t actually that important, we could instead use some space demonstrating that a first-order analysis is wholly unsuitable for solving modern problems stemming from the big data revolution. Or, it might so happen that the analysis’s soundness is not the main concern, in which case we can use that space a better way.
I hope it is becoming clear that while some work is naturally inward facing and some outward facing, as researchers we can make choices about which direction our work faces. The point of this piece is that we should always at least consider making our work more outward facing. The cost would be that some of our inner research monologue never sees the light of day. The benefit is that perhaps we learn more about the world outside of our own work, helping others to understand its importance and helping ourselves choose more interesting and important problems to work on.
15 responses to “Inward vs. Outward Facing Research”
Most research papers are boring or unreadable precisely because they are overly focused on presenting the details of the work.
Daniel, I was trying to find a nice way to say that.
I think some of the choices you’re describing are artificial and purely related to the page limit restrictions enforced by computer science conferences. When I write a paper with a proof, I don’t want to have to choose between cutting the proof out or cutting the justifications out. I want to include both in the paper.
I’m not convinced that it makes sense to criticize the choices people do when forced to butcher a paper to satisfy page limits. It surely affect the conference reviewers (and arguably the page limit is in their benefit as it reduces the work they have to do, maybe, by forcing content removal), but outside this specific handful of people (and I don’t think your post was about the reviewing process) people should just go read the long version that has all the content as the researchers wrote it from the start.
Also I think there is more value than you suggest in history. That’s something I hear a lot: “don’t tell the history of the work, you’re more interested by it than other people”. But that’s something I actually often miss from other’s work. What other variants would be possible? Which have you tried? Why didn’t they work?
Of course this should not be an excuse for hundred additional pages of lazy writing (there is value in condensing the text, and effort required that we *should* indeed requite) or badly-thought-out presentation order. But I’d rather like to see the two faces of the work instead of considering normal to force authors to make stupid choices between cutting the technical content of the work and cutting the context that let readers understand the content.
Hi gasche, I agree that page limits force people to make arbitrary choices, but I don’t think that’s the main issue. As Daniel says, there’s a lot of boring and unreadable stuff being produced by very smart people. As far as I can tell, one of the main reasons is that it’s easy to lose track of the audience.
Nice post. I’d like to add that there is (/should be) a big difference between written work and presentations vis a vis the inward/outward balance. The vast majority of conference presentations I’ve seen spend too much time on the inward side. I think the default for short (i.e. in the 10-30 minutes ballpark) presentations should be almost all background, motivation and broader implications of the work. I usually only want to see a sketch of the technical meat. If I’m interested enough, I’ll track down a written version. I think there’s more room for getting into internal matters in longer (hour+) lectures.
Also, while questions related to framing and presentation are important, in my cynical moments I feel like most research projects have had disappointingly little TLC given to external concerns at all.
Ben, definitely agree about paper vs. presentation. It’s often a bit of a problem, and as a result talks only engage people who are already interested and knowledgeable instead of attracting a new audience.
A short summary of this post might very well be: “Why should I care ? “. In other words (and this is what I usually tell my students), any form of research communication (a paper, a talk, or whatever) has to answer this question for the target audience. In the case of a paper, an ‘outward’ focus is the attempt to answer this question.
Suresh, yep. Or, as I like to annoy my students by saying: “That’s nice. But whose life does it make better?”
Well that might be too high a bar. I can care about something even if it doesn’t make someone’s life better :).
Well, making things better is a reasonable goal when living on public money.
While I think situating your work is important, in my area I find the need to say something outward facing tends to make things worse. The connections are not always clear (which should be fine!) and there’s an escalation that happens which isn’t helpful. Superficial “and this is super duper important because bug are bad” detract more than they help.
I also disagree about the idea that presentations should be largely nontechnical. Presentations are often a great way of helping people grasp the technical bits which might be hard to grasp with only one modality available. Contrariwise, often everyone in the audience is well aware of the range of applications and doesn’t need a lot of motivation slides.
I’ll take as much clarity and insight as I can get. That requires fitting the orientation of the presentation to bothe the topic and the audience. And that’s my banality if the day!
To be published, research has to get over a certain novelty or difficulty bar that is a construction of the community’s standards for publication. If an idea is too simple or too easy, even if elegant, it runs the risk of appearing unsophisticated and “beneath” a community’s self-image. Thus overt sophistication of otherwise simple ideas such as adding unjustly complex theory and theorems to otherwise intuitive results is one symptom of such a need. I actually think that this kind of needless sophistication is more rampant than most people feel comfortable admitting. It serves as a barrier to keep outsiders from publishing in a field, preserving territory–publishing opportunities and funding areas. But worse it also handicaps research’s broader applicability when notations become inscrutable or distracting, steeping knowledge in esoteric, ritualistic dressings that also warn away casual interest.
Whether intentional or unintentional, readers feel less capable of wandering into new fields and decoding useful results.
I feel this way when reading type theory papers, especially ones that intersect a particular aspect of implementation that I might already intuitively understand. The search for elegant formalisms here has lead to notational conventions whose puzzling riddles, when unravelled, mostly provoke a guffaw rather than an ah-ha, since no one would ever, ever, ever implement them that way on a computer. But surprisingly neat things are hidden in these notations too–so that one is never quite sure whether a whole heap symbols contains a brilliant insight that might change the way one thinks about mathematical constructions or a stupid schlepp of symbols that proves something trivial.
Bijan, I agree that superficial or deceptive indicators of outward-facingness are awful. In fact, I almost included in the post the same example you use: “Bugs in safety-critical software are bad. We turn our attention to Lemma 1…”
There’s a lot of room for personal preference and if you can give great talks containing all of the technical details then of course you should do that. But it’s not a style that I’ve observed working well very often.
Ben, I often feel the way you do about this stuff. There’s lots of very clever and useful material out there and it’s soooo much work to extract it in its simplest form.
Another way to say all this is that in engineering, the simplest solution to a problem is the correct one. To the extent that CS research is a branch of engineering, unnecessary complexity is always wrong. We tend to forget that at paper submission time.
As a frequent reviewer and very frequent reader of papers, I have to say that removing page limits seems like one of those things that would do some good and much more harm. The occasional paper is too short, sure, and that’s what tech reports are for, but the attention of readers is the most precious and limited resource around.