Most papers are divided into roughly 5 sections: what we know, what we wondered, what we tried, what we found, and what it means, followed by a set of citations. You should look through these carefully to figure out what the foundational papers in your field are.
Some exceptions to this are literature reviews, which try to summarize all recent progress in a field and document the state of the art, and problem statements, which suggest directions for new research by pointing out a new or overlooked issue, and which are typically a prequel to grant applications.
You need to figure out whether the goal of people handing you papers is for you to become expert in the topic by fully understanding the methods and results, or to just trust that the papers you receive are the state of the art in this field and think about how to implement their conclusions in software, perhaps translating the key mathematical assertions or pseudocode algorithms into working prototypes.
Get used to looking up the paper online (the doi:// link on most papers will take you to the journal of original publication), because you can also check what papers have subsequently cited the work, and download the Supplementary Information, which usually exists as a 2nd pdf that goes into greater detail about methodology, intended to help a lab assistant or non-expert (ie you) reproduce the results. They are typically written in a more casual style and often include links to code or datasets, as well as practical information about what equipment was used or pitfalls to be avoided. The SI can often help you make sense of an otherwise confusing paper.
Remember, papers are not tutorials. They're checklists intended to back up an argument for reconsidering the conventional wisdom in a field. They may be trying to add detail, or show that one piece of knowledge sheds light on another topic in an unexpected way, resolve (or at least make tractable) some knotty problem that has caused progress in some direction to come to a halt, or (occasionally) to suggest that the conventional wisdom is actually wrong and some new concept explains prior results more economically or completely. Papers that trumpet their own importance usually aren't; papers that express surprise often are.
I think I'm on the "just trust that the papers you receive are the state of the art in this field and think about how to implement their conclusions in software" path. I actually prefer that, because I'm not really much of an academic. I would prefer to focus on the code and implementation details versus the theory stuff.
Distilling it down from a really abstract level to something to implement is hard though. To be fair, I'm just starting out with this so it should get easier from here I suppose.
In my experience, academic papers are written by academics to be read by other academics. Depending on the state of the field, there often is a huge gap between the theory and practice.
Unless you are already an expert in your field, you may need to read many of the cited papers as well in order to know what paths have already been taken and why the present paper improves upon them. Unfortunately negative results are rarely published so there is an ever present danger of going down an obvious path which turns out to be a dead-end.
Some exceptions to this are literature reviews, which try to summarize all recent progress in a field and document the state of the art, and problem statements, which suggest directions for new research by pointing out a new or overlooked issue, and which are typically a prequel to grant applications.
You need to figure out whether the goal of people handing you papers is for you to become expert in the topic by fully understanding the methods and results, or to just trust that the papers you receive are the state of the art in this field and think about how to implement their conclusions in software, perhaps translating the key mathematical assertions or pseudocode algorithms into working prototypes.
Get used to looking up the paper online (the doi:// link on most papers will take you to the journal of original publication), because you can also check what papers have subsequently cited the work, and download the Supplementary Information, which usually exists as a 2nd pdf that goes into greater detail about methodology, intended to help a lab assistant or non-expert (ie you) reproduce the results. They are typically written in a more casual style and often include links to code or datasets, as well as practical information about what equipment was used or pitfalls to be avoided. The SI can often help you make sense of an otherwise confusing paper.
Remember, papers are not tutorials. They're checklists intended to back up an argument for reconsidering the conventional wisdom in a field. They may be trying to add detail, or show that one piece of knowledge sheds light on another topic in an unexpected way, resolve (or at least make tractable) some knotty problem that has caused progress in some direction to come to a halt, or (occasionally) to suggest that the conventional wisdom is actually wrong and some new concept explains prior results more economically or completely. Papers that trumpet their own importance usually aren't; papers that express surprise often are.