[dnadler]

While that wasn’t my experience as a junior developer, this is something that I used to do with academic papers.

I would read it start to finish. Later on, I learned to read the abstract, then jump to either the conclusion or some specific part of the motivation or results that was interesting. To be fair, I’m still not great at reading these kinds of things, but from what I understand, reading it start to finish is usually not the best approach.

So, I think I agree that this is not really common with code, but maybe this can be generalized a bit.

[disgruntledphd2]

> reading it start to finish is usually not the best approach.

It really, really depends on who you are and what your goal is. If it's your area, then you can probably skim the introduction and then forensically study methods and results, mostly ignore conclusion.

However, if you're just starting in an area, the opposite parts are often more helpful, as they'll provide useful context about related work.

[Aurornis]

> this is something that I used to do with academic papers

Academic papers are designed to be read from start to finish. They have an abstract to set the stage, an introduction, a more detailed setup of the problem, some results, and a conclusion in order.

A structured, single-document academic paper is not analogous to a multi-file codebase.

[rorytbyrne]

No, they are designed to elucidate the author's thought process - not the reader's learning process. There's a subtle, but important difference.

Also: https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape...

[p1esk]

they are designed to elucidate the author's thought process - not the reader's learning process

No, it’s exactly the opposite: when I write papers I follow a rigid template of what a reader (reviewer) expects to see. Abstract, intro, prior/related work, main claim or result, experiments supporting the claim, conclusion, citations. There’s no room or expectation to explain any of the thought process that led to the claim or discovery.

Vast majority of papers follow this template.

[jcgrillo]

The academic paper analogy is interesting, because code and papers are meant to do the exact same thing: communicate ideas to colleagues. Code written by a small group of competent programmers with a clear, shared vision is therefore a lot easier to read than code written by a large group of programmers who are just desperately trying to crush enough jira story points that they don't get noticed at the next performance review.

The difference is usually papers written that badly don't go into "production"--they don't pass review.

I usually read code top-to-bottom (at least on a first pass) in two ways--both root-to-leaf in the directory/package structure and top-to-bottom in each source file. Only then when I've developed some theory of what it's about do I "jump around" and follow e.g. xref-find-references. This is exactly analogous to how I approach academic papers.

I think the idea that you can't (or shouldn't?) approach code this way is a psychological adaptation to working on extremely badly wrought codebases day in and day out. Because the more you truly understand about them the more depressing it gets. Better just to crush those jira points and not think too much.

[the_af]

You're supposed to read academic papers from start to finish.

[baq]

You're supposed to read the abstract, preferably the bottom half first to see if there are conclusions there, then proceed to the conclusions if the abstract is insufficient. Once you're through with that, you can skim the introduction and decide if the paper is worth your attention.

Reading start to finish is only worth it if you're interested in the gory details, I'm usually not.

[jghn]

I was taught to read the abstract, then the conclusion, then look at the figures, and maybe dig into other sections if there's something that drew my interest.

Given the variety of responses here, I wonder if some of this is domain specific.

[nis251413]

It depends also on what you want to get from the article. Usually I focus on the methods section to really understand what the paper did (usually I read experimental papers in cognitive science/neuroscience). I may read parts of the results, but hopefully they have figures that summarize them so I do not have to read much. I rarely read the conclusion section and in general I do not care much about how authors interpret their results, because people can make up anything and if one does not read the methods can get really mislead by the authors' biases.

[dnadler]

It’s interesting how many different opinions there are in this thread! Perhaps it really varies by field.

I was reading mostly neuroscience papers when I was taught this method as an undergrad (though the details are a bit fuzzy these days).

I’d bet it also varies quite a bit with expertise/familiarity with the material. A newcomer will have a hard time understanding the methodology of a niche paper in neuroscience, for example, but the concepts communicated in the abstract and other summary sections are quite valuable.

[fsmv]

I learned very quickly reading math papers that you should not get stuck staring at the formulas, read the rest first and let them explain the formulas.

I would not say it should be read start to finish, I often had to read over parts multiple times to understand it.