Hire developers Community Blog Find a dev job Log in
Close menu
Tech Career Insights: Reading Research Papers Can Be Easy?!
Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Reading Research Papers Can Be Easy?!

20 March 2019, by Michael Gant

Reading research papers can be tiring, confusing and overwhelming, especially when the topic is cutting edge or the title doesn’t make sense. However, these are the papers that are often the most interesting. With some effort, you can work to understand what’s going on and even feel confident enough to explain the idea to others. Here, I’ll share my approach to reading and implementing papers, as well as give some tips that help me make them more enjoyable to read and easier to understand.

Michael-G_Piles-of-research_Inner-article-02

In my Honours year at UCT, I began reading research papers for assignments and my final project. It took me a while to figure out a reading routine for tackling unfamiliar research papers, especially since I have a tendency to lose motivation and switch focus to more practical work. I found the first few papers to be particularly intimidating because:

  • The language was very academic,
  • There were summarised math formulas that I could barely read, and
  • The concepts seemed super abstract.

A turning point

I realised that I hadn’t been reading papers effectively when I entered a post-graduate, research paper competition. We had to write a paper to showcase an application of our work, and so, I chose to extend my Honours project with a cool statistical test from a paper that my supervisor had urged me to read. The test is called the Improved Statistical Arbitrage Test and to implement it I had to:

  1. Understand why this test would be useful to me,
  2. Make the theory practical by coding up the test, and
  3. Check that what I had done was correct.

The first point took me a while since I didn’t understand the theory behind the test when I first read the paper. Eventually, I felt like I had kind of grasped it and so I moved onto the second task. I coded up what I thought was correct and I ended up with a very simple implementation of the test. I thought that there was no way it could be that simple but, from what I understood, it seemed fine… I was very wrong!

I used the test on the data from my paper and obtained some interesting results. They were believable and, without thinking to check my implementation of the test against the original paper’s results, I wrote up my findings and submitted my paper for the competition. Only a week later, another Masters student, who was working on the test as well, asked me how I’d figured out the simulation part of the test. I hadn’t done any simulation part… And that’s when I realised I’d missed a massive part of the test.

Reading through the simulation part was a bit of a shock - it felt like I was reading a completely new paper! I could vaguely remember reading this part and thinking that it probably related to a more complex version of the test, and so I skipped over it.

Since my understanding of the paper was poor, skipping such an integral part of the test didn’t set off any alarm bells. To get on the right path, I had to scrap my understanding of the paper, and essentially begin from scratch.

After a few effective rereads and two collaboration sessions, I had a working ‘Test for Statistical Arbitrage’ that returned results similar to the original paper. But, more importantly, I had a realisation about how to approach research papers more effectively.

This realisation led me to be more cognisant about what I was reading, and I started following some advice from Machine Learning Youtuber, Siraj Rival. I can’t read as many papers as he does, but I liked his reading approach and adapted it to how I learn. Here’s an outline of how I read research papers now.

Actually read the abstract!

Most people will already know this step, but I have to emphasise it for the foolish, seemingly brave people like me who jump into the deep end without testing how deep the water is first. The abstract is a really important part of a research paper, but young, naive me saw it as unnecessary and a waste of time. Simply put, the abstract puts the whole paper in context. It positions your mind in the correct area, so that you know what general concepts to relate to and what to focus on.

Read the abstract!

When I didn’t read the abstract, I got lost within the first few pages, made incorrect associations and developed a flawed understanding that eventually forced me to start reading from the beginning.

Now, instead of skipping the abstract, I try and do the following:

  • I read it thoroughly and try to explain the ideas to myself in an intuitive manner, using only plain and simple language. If I’m unable to do this, then I don’t understand it well enough yet and need to Google some of the terms used.
  • I try and link terms in the abstract to topics that I’m familiar with as this roots the ideas in my mind a bit more firmly.

Just by approaching the abstract in this way, my initial read through became more enjoyable and far less daunting than before. Understanding the abstract put me in the mindset to recognise what was going on, which led to me feeling more self-assured and eager to tackle the denser parts of the paper.

Skim the paper

You might be tempted to move onto a full read-through next, but I’d caution you against that. If you decide to barge ahead, you’ll likely run into a few serious hurdles like:

  • Decreased motivation,
  • Loss of focus, and
  • An inability to understand key points.

To me, the most serious hurdle is decreased motivation, since I experienced it when trying to read the whole Test for Statistical Arbitrage paper for the first time. The only thing that I remember was that I stopped about six pages in because nothing made sense and I didn’t want to carry on. The new concepts, terms, definitions and proofs that I was bombarded with, took its toll on my focus. The less focused I was, the less I understood.

I quickly realised that I was trying to shove too many new concepts into my brain all at once, and that wasn’t going to work for me. So I decided to skim through the paper before the full read-through. This allowed me to process the new information better and to slowly build my knowledge on top of concepts that I already understood. Most importantly, I gained motivation instead of losing it and was able to understand the general idea of the paper.

For me, skimming means that I breeze through the paper:

  • I skip a lot of the motivations and justifications and just focus on statements. I don’t get stuck on trying to understand what I don’t get at a first glance, because I just move on. This way, the easy concepts are picked up and I’m not overwhelmed by concepts that are far more difficult.
  • I also try to highlight interesting references, statements and results because these are things that I definitely want to focus on in subsequent read throughs. You’ll have to use your intuition on ‘interesting-ness’ to decide what to highlight - just don’t highlight everything or you’ll never finish the paper.

Focus on the conclusion

At this point, you should have a pretty good idea of what the paper covers. While you won’t have an in-depth understanding, you have built the foundation for further read-throughs. This will really help with tackling the denser sections later on, as you’re at least slightly familiar with the content and aren’t seeing the concepts for the first time.

As one last relevance-check for myself, I do a slow and proper read through of the conclusion. The conclusion aims to:

  • Sum up what the whole paper managed or didn’t manage to achieve.
  • Tell you the “spoilers” of the paper, so that, when you read through the body, you’ll have some foresight to understand the methods and results better.

By focusing on the conclusion, I can decide whether it’s worth continuing with a full read-through. I consider the original reason for picking up the paper, and if that reason is being satisfied I’ll keep going.

In the past, that reason tended to be “my supervisor told me to”, but more recently I’ve found that I can’t just be spoon fed the answer. I’ve got my own questions about my work, like “How do I model latent variables?” If a paper seems like it will answer this question, then I know that my reason for continuing on with the read-through is valid.

This helps me stay on topic and use my time efficiently.

Read through the paper and build an MVP

I used to avoid the full read-through because I thought that a basic understanding was enough to get by and be efficient. However, lecturers eventually stop giving you all the answers and a basic understanding isn’t enough at Masters’ level. Now, I’m actually excited to do a full read-through as I’ve experienced how it can feel to have a greater level of understanding. The rush of endorphins that I get from those “Aha!” moments is all it takes to motivate me to push through.

The full read-through should take longer than the previous steps, but you’re prepared for it because you’ve read the abstract, skimmed through the body and you’ve seen the spoilers.

Your aim is to understand more than you did before.

To do this, I like to engage and debate the concepts that I am comfortable with. This may mean skimming through some of the papers that are referenced, working through proofs and maybe implementing a practical component. In essence, I’m working to expand my basic knowledge to a proficient level by diving deeper into the content.

For me, a lot of the papers that I read contained some statistical model that was coded up. The implementation involved a lot of programming from scratch, since the papers did not provide their code. But, since this was a first read-through, I would only focus on a basic and manageable component to help me understand the paper. This means I would try to make a quick, Minimum Viable Product (MVP), or as close to one as I could without going down the rabbit hole.

I found that this was actually a decent test of my understanding because, if my results matched the paper’s results, this meant that I understood the theory well enough. However, this will not always be the case, especially in the first read-through. More often than not, I get very different results, but at least I know that I have more work to do and where to focus my efforts.

Re-read and implement

You’ve reached the summit only to see another peak ahead, but it’s not as high and you’re stronger and more prepared. This is how you should be feeling after the full-read through. You’re not an expert on the paper yet but, if you want to be, you’re definitely going to need to reread it many times. You’ll still pick up new concepts that you’ve missed, as your understanding wasn’t at the level where you would notice the very nuanced ideas.

At this point, I’m usually itching to implement any practical components. This is the perfect time because I have enough of an understanding to get started, and as I read more, I find that I am able to implement even more theory. This is the stage where I properly start coding any of the statistical models, while using the MVPs as references.

However, motivation can be a problem at this point because the topic isn’t as new and exciting as before. To help this, I turn to collaboration and presentation to keep me excited and help deepen my understanding of the problem that I am addressing.

Collaborate with classmates

I find that collaborating on a paper is an efficient way to fix some of the gaps in my understanding, because it gives me the chance to hear the concepts explained from a different perspective. Multiple people are less likely to miss key concepts than a single person, so this is super helpful.

In my last year at university, a few of my assignments involved reading and implementing research papers. There were two that I didn’t really get, and wasn’t that interested in and eventually I fell behind. Fortunately, a classmate was willing to help and, since he was struggling with the coding section, I could take what he had figured out and use that to explain the implementation side.

Despite the reduction in workload, I still had to read through the paper, but now at least I was more motivated, had a better foundation and someone to bounce questions off of. This led to both of us gaining a much deeper understanding of the topic than we would have had if we had worked on it alone.

Present the paper

The presentation that I am referring to here is when you take a research paper that you’ve read and understand, and then present it to a research group or at a meetup event. For me, taking a research paper that I’ve read and understood and then presenting it to a research group or at a meetup event is definitely one of the more difficult actions. I’ve found, though that it is how I learn the most because I’m forced to really question my understanding and package it in a digestible form for others.

My first presentation was for one of my Masters’ modules and, although I thought I had the idea of Independent Component Analysis (ICA) down, I stumbled badly through a practice session in front of two classmates. The drive to not embarrass myself was more than enough to push me to a greater level of understanding and I realised how beneficial presenting a paper could be. Getting better takes practice, there are no shortcuts or ways around it, and this makes presenting brilliant for achieving an expert-level understanding.

The first time you present to an audience is the scariest, but the next one is great fun and you learn a lot about the topic at hand, and how well you’ve understood it!

Hopefully after reading this, you’ll be able to think more about the way that you read and implement research papers. These steps have worked well for me, but are open to interpretation. Not everyone learns in the same way but, by challenging the way you learn, you may find different and better ways of understanding. I’m always open to the idea of being challenged and having to defend the way I do something, so if you feel you have a better step, or a completely different methodology, I’d love to hear it!


Michael Gant is an Associate Software Engineer for Countercept, based in Johannesburg. He is currently finishing his Masters in Advanced Analytics and Decision Sciences at UCT part-time with his main area of focus being Statistical Finance and Machine Learning. In his spare time, he enjoys reading, learning new sports and playing online games with friends.

Source-banner--1-

Your next developer job is waiting for you
On OfferZen, companies reach out to you with upfront role, tech stack, and salary info.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe to our blog

Don’t miss out on cool content. Every week we add new content to our blog, subscribe now.

By subscribing you consent to receive OfferZen’s newsletter and agree to our Privacy Policy and use of cookies.