When I was writing my master’s thesis, I discovered that to finish the thesis I needed more than divine inspiration and mathematical skill. I needed discipline and a good dose of tenacity. I started collecting productivity hacks and tips and tricks on writing research papers. This article summarizes the best tips I found.
Amber Davis is a researcher and coach of PhD-students. She wrote three guest posts for the blog PhD Talk. In her articles, she focuses on taking good care of yourself when you’re doing research by making sure you get enough sleep, exercise and time off. She also stresses the importance of staying positive, even if you’re stuck with your research. Given that a lot of graduate students live on nightly writing streaks, self-help books and ramen noodles, reading these articles can’t hurt.
Don’t expect to be able to do difficult work for 6 to 12 hours per day. Experience learns that we can concentrate intensely on a difficult task for about 4 hours a day before our mental energy is depleted.
Make your work environment fit for concentrated work. Surround yourself with tools and people that promote productivity.
I also like the productivity posts by associate professor Matt Might.
If you are interested in forming new habits of productivity, Leo Babauta has written a lot on this topic on Zen Habits.
If you want to know how and why to train your concentration, take a look at the non-fiction book Deep Work by Cal Newport.
Stolen laptops, power surges, broken hard drives and fires are part of reality. When you’re doing research, take precautions so that you don’t lose the products of your blood, sweat and tears. Back-up regularly and often. Use USBs, cloud storage, or an old laptop.
Even better than a back-up system is a version control system. This allows you to experiment with your work, and set it back to an earlier version if your experimenting doesn’t work out. Even better: you can try different paths of coding/research in different branches.
Although cloud storage frameworks like dropbox sometimes have versioning capabilities, I prefer
git scares you, try learning it with the resources on Github.
Keeping a research diary has many advantages. It serves as a log of everything you encounter, read, do and ponder upon during your research project.
If for whatever reason you cannot work on your project for a while, your research log will tell you exactly where you left off.
Writing things down when you’re stuck will force you to formulate your problem clearly, which is often the first step on the road to finding the answer.
I find that a normal office document does the trick, but some people prefer to use fancy pens and moleskines to motivate them to write things down neatly.
I take my inspiration from Edsger Dijkstra, a famous Dutch computer scientist, who wrote an enormous amount of technical notes and essays (“EWDs”) on a wide variety of topics. You can browse the archive of all EWDs here.
When I was an undergraduate student, the thought of asking other people for help filled me with fear. I had to learn the hard way that asking for people does not make you a failure. Besides, most people are happy to help – just formulate your questions clearly and ask them politely if they have the time.
Asking for help has two major advantages.
Whenever you’re stuck, you might get unstuck a little sooner, which makes you more efficient. Secondly, talking about your problems forces you to clearly formulate your thoughts – which might lead to new insights as well.
When you read large amounts of texts for your research, consider organising these sources in a meaningful way. Doing this consistently during the research phase can save you a lot of time during the writing phase.
I like to maintain a list of all the texts I have read. In this list I keep track of the following properties:
If a certain text is particularly important for my research, I will also annotate all paragraphs with a short description (‘proof sketch’, ‘description used hardware’, or ‘research validation’. Note that this only works for well-written papers, where every paragraph has at most one goal. An alternative is highlighting the most important sentences with brightly coloured markers.
These annotations save me a lot of time when I am citing my sources during the writing phase, since I can find important pieces of information back in a matter of seconds.
My favourite workflow for doing research consists of separate phases of doing actual research, writing and editing. The first part, doing actual research, makes up the largest part of the work. It encompasses ‘getting your hands dirty’ in an academic way: reading through enormous amounts of research papers, installing tools, testing tools, using tools, writing code, experimenting with mathematical proofs, etc. The main problem is that most people put off writing until they are done with doing research. I think this is a mistake.
In my experience, it is better to do a few hours (1-4) of research, and afterwards process everything you have learned by writing it down. Note that this doesn’t mean that you have to use this written material literally in your final research paper. However, it can be wise to record a few important citations (if you’ve been reading a paper), to write an evaluation of the proof strategies you’ve chosen so far (when proofwriting), or to describe why you’ve made a certain choice in your implementation (when coding).
During the writing phase, I try not to judge too harshly how I phrase things. In my experience, this gets in the way of writing efficiently and effectively. For writing you need a creative mindset, while for editing you need a judging mindset. Because the two phases require two different mindsets, I postpone judging the quality of the text to the editing phase.
Seriously, just start writing.
Another nice strategy for writing is to structure your research paper like a tree object: the paper itself is the root node and all sections and subsections are child nodes. The leaf nodes of the tree should become the paragraphs of your paper. Each node in the tree should have a main message or a communication goal. If you have written down the argumentation structure of your research paper as a tree object, the only thing left to do is to transform each node into a neat paragraph.
Maybe I will someday write another blogpost on writing well. Until that time, enjoy this hilarious article by Steven Pinker:
Judith van Stegeren is a Dutch computer scientist. She is working as PhD candidate at the University of Twente, where she researches natural language generation for the video games industry. She occassionaly works as a consultant in data engineering for textual data.