I’m running a bunch of experiments this week—sort of a bigger run of a set of proof-of-concept experiments I did late last summer. Basically I’m trying to determine how much of an effect changing the transport mechanism of video data over a network affects the measured characteristics of the video data. This may have a big effect on the measurement system I’m trying to design: we need to know what we’re measuring before we can build a system to measure it!
But that’s not really the point of the post.
What strikes me as I run these experiments is how much I rely on writing as both a research tool and an idea generator.
In the past, my research followed more of a linear approach: define the problem, come up with a hypothesis, design the experiment to test the hypothesis (or, let’s face it, find the hypothesis in some cases), run the experiments, (rerun the experiments because something got screwed up), analyze the resulting data, refine the problem/hypothesis, redesign the experiment, etc. Only after this cycle was complete did writing even appear on the scene. Writing up the results, experiments, hypothesis, etc. was the last stage of the process, and signaled that the research process was winding down for the project in question.
Now, my research is definitely more circular, and writing appears multiple times in the research cycle. Sometimes I’ll write right away, as soon as I define the problem, as a way of thinking through my ideas. (A lit review is a good way to do this.) More often, though, writing occurs as I run the experiments and collect and analyze the data.
It turns out that writing is very useful at this stage in the game. Practically speaking, writing up results as you generate them really comes in handy for future papers: you have a stable of already-packaged results that can be inserted into various papers, you can assemble conference papers and journal papers with shorter lead times, etc. But I find it also helps refine my thinking. By writing up results as I analyze them, I focus more clearly on my intended audience: What would my peers think about my results? What questions might they have about what I’m discussing, or what questions would they have about these results? What are the most likely criticisms that a peer reviewer would have? This helps me clarify my own arguments and sometimes even guides the analysis I end up doing. It helps me uncover holes in my own logic and points I’m glossing over. It also helps me figure out, more quickly, what new questions this data raises, and helps me enter the experiment/analysis refinement stage sooner (and also serves as a better guide to the refinement process).
It also helps with the “research amnesia” problem. Often, I’ll get a great idea for a new project, or a new aspect of a question to ask. It turns out, though, that I will often have the same great idea more than once. So the first thing I do when inspiration strikes is to see if I’ve tried to answer that question before. 90% of the time, I have. This saves me time, because I don’t end up repeatedly going down the same dead-end path. But it works the other way too: sometimes revisiting these dead ends means I notice something that escaped my attention the first time, and which changes the whole analysis, so that a dead end becomes a new fruitful line of research. (This is how my 2 most recent conference papers came to be!)
So this week, I’m multitasking: running experiments, analyzing the data as it becomes available, and writing as soon as an analysis is complete. I definitely won’t completely answer the questions I set out to answer—I’ve already found some holes in my logic!—but I know that I’ll be much, much closer to the eventual answer as a result.
I just wish I had learned this valuable research skill sooner in my career!
This is what a computer scientist looks like 