In writing the Anatomy posts, I realized an important ingredient to successful research: writing the introduction first. First. First, as in before you “do the research.” Before you design the experiment. Before you write the related work. Before you tap out a single line of code. Write the introduction first.
Most students recoil at the idea. I did. After all, why write anything before you have results to write about?
Because you do not understand your research until you have written the introduction. Recall the six points that you need to tell your reviewers in your introduction:
- A description of the high-level domain / environment
- A key problem that happens in this high-level domain
- Current solutions to that key problem
- A problem with the current solutions
- A glimpse at how you solve the problem in (4)
- An overview of your evaluation / experiment results
If you cannot fill in these six points right now, it means you do not understand your research. You may think you understand it, but you don’t. Here’s a typical situation. A graduate student starts in June on a summer project. After two months it’s August 1st and the student has downloaded 3 gigantic datasets, written clever scripts to organize them as a SQL database, and, with great effort, written a C program to compute a new metric on the datasets via the SQL tables. In a couple days the student loads all the metrics into an Excel spreadsheet. After struggling with XLStat for a few hours the student manages to calculate a statistical hypothesis test comparing the new metric to some old metrics. And tada! The new metric provides statistically-significant improvement to all previous metrics! Hurray! A Publishable Result!
Then comes the start of the academic year. Someone asks the student, “what did you do this summer?” And the student responds:
Well, I worked with Dr. Soandso and programmed a tool that extracts data from SQL database and processes it using a math library along with some supporting functions I had to write.
You can hear it now:
Oh, so what problem did you solve?
Hmm, the definitely the hardest problem I solved was that the SQL library I was using at first only could access MySQL databases, but the database had to be in PostgreSQL, so we had to … blah blah blah
I did this all the time. I didn’t understand my own research! How embarrassing!
Zoom out and ask yourself: what if you were talking to a reporter? What would you tell him or her that you work on? How would your research affect the public, even in a very small way? Maybe the metric you calculated was a way of measuring some qualities of corn stocks (protein and fat content, perhaps). And your new metric is more-correlated to price than all other metrics (the statistically-significant result over 3 datasets). That means you created a tool that helps farmers grow better crops!
Now the reporter is interested. The public hears of your discovery, and is excited enough to pay you its hard-earned money via taxes to continue your research. The public, the farmer, and you all benefit. You can now be a happy part of the virtuous cycle of scientific research described in a book by Pietra Rivoli.
Well, you could be a happy part of the virtuous cycle, if you understood your own research. Understood the point of your own research, that is. Quick exercise, answer in three sentences max: what did the student I mentioned above do this summer for research? How about:
The student created a tool to help farmers grow better corn. The tool is a better way for farmers to determine the quality of the corn growing in their fields. It works by measuring the protein and fat content in a sample of the corn, and comparing these to historical data.
Makes total sense!
If you write a good introduction first, you will be forced to answer these questions up front. You will be forced to understand how your research fits into the big picture. You will know who benefits and why. You will feel much more confident about your work, and will be able to work more quickly.
Now for practice. 🙂 What did you do for your research?