At one point or another, something in your research will stall. Or it be proven useless, incorrect, or already shown in paper X. Co-authors and journals will take months to get back to you. Or your numerical simulation will take ages to finish. This is why I love the scattered approach to research. I don’t like to be doing one thing. I like to be doing 8 things. At any given time, my research to-do list looks something like this:
- Read the following 20 papers: …
- Write the code
- Debug the code
- Set up a run/ check progress on a variety of runs
- Edit papers and figures for publication
- Write up preliminary results
- Work on the Standard Slides (Slides I keep around for the unexpected talk… or to make the expected talk much smoother.)
- Learn new thing (a new programming language, or mathematical topic I am unfamiliar with)
- Try to Prove Something
In college I had a roommate who while procrastinating writing a paper cleaned our apartment, did all her laundry and cleaned out her inbox. It was only when she had to choose between cleaning out her closet and the paper that she started writing. I learned something important from her: she was making procrastination work for her (and me!). She didn’t waste time, but she allowed herself to put things off, waiting for inspiration to strike. I have since taken this lesson to heart.
There are some drawbacks to this method. I don’t always make a lot of progress on a given task each week, and it can sometimes feel like I’m not moving forward or that there are an insurmountable number of tasks ahead of me. Meetings with my advisor can be scattered, and we don’t we don’t always get to all the topics I want to discuss. (I should mention here that my advisor is also a do-8-things person, and thankfully understands my scattered ramblings better for it.) And there are weeks where I have to say “I didn’t work on that this week.”
A critical danger is spinning your wheels on projects that are not critical to your research, putting off more challenging tasks indefinitely.
There are also some benefits. When I get stuck, I don’t have to get frustrated. I can work on a different project until I feel more inspired. This switching also allows me to work longer. When I’m burnt out on coding, writing up results can be a comparatively easy task, and a joy after an afternoon of banging my head against my keyboard. When I can’t think of another thing to try while proving something, I take a break and read some related papers, hoping for the idea I need to appear. And all of the breaks that could be tetris or facebook become things I should be doing anyways!