Last summer, I was tasked with writing a report about the research I completed and submitting it to my supervisor by the end of the summer. I, of course, had never done this kind of writing before, so I learned several lessons. The hard way. The learning process was super painful, but it did come in handy when I had to write two other research reports in my classes last fall. Here are a few of the lessons I learned.

I just finished a blog post where I discuss things I’ve recently learned about how to read research papers. I almost included this as a point in that post, but I think it’s important enough to warrant its own article.

Here’s the idea: you absolutely should not be reading the sections of a research paper in order.

It took me a while to learn this one – I can’t remember if I first read this advice somewhere, if someone told it to me, or if I reverse-engineered it from advice I got about how to write papers. It doesn’t matter which one came first, really – my point is that I only found this out in a roundabout way through googling and trial and error and harassing people with questions.

Last summer, I spent a good chunk of my time doing an undergraduate research project during which I worked on a project largely by myself, under the supervision of a math professor. I then took a graduate level course in a related area this fall, where I investigated the theoretical underpinning behind my summer project. I had no idea what I was doing or what I had gotten myself into. As a result, I learned a lot, and tried to keep note of the various things I had learned. This is the first installment, on what I learned from trying to read math and theoretical CS papers.

When I’m trying to approach a highly specialized topic for the first time, one of my tactics is to find a recording of a research-geared workshop about it and watch it as my introductory crash course. The benefits of this are as follows:

• I am learning about the subject from (hopefully) a credible expert in the field.
• Workshops and talks usually try to be self-contained, which means basic background info will likely be given and I won’t have to pore through 10 different research papers, searching for an obscure definition, in vain.
• Talks typically have the benefit of including visuals and informal intuition conveyed by the speaker, which generally won’t make it into academic papers, because they’re not rigorous. However, the visuals and informal statements and intuition are invaluable for gaining a better understanding of the information.
• The speaker will generally include a bibliography and mention related works, which is a great jumping off point for further investigation and saves me from having to figure out what the seminal sources are myself.

However, there are also some drawbacks: