> Remember your first day reading production code? You probably did what I did - start at line 1, read every file top to bottom, get lost in the details.

Now it reads:

> Remember your first day reading production code? Without any experience with handling mature codebases, you probably quickly get lost in the details.

That’s a trivial change to make for a line that did not receive the feedback that the author wanted. If that’s the case, maybe the text was more about saying what people wanted to hear than honestly portraying how to make AI read code better.

Top to bottom left to right is how we read text (unless you are using Arabic or Hebrew!), the analogy was fine IMO. Don’t let one HN comment shake your confidence, while people here may be well intentioned they are not always right.

I've been a lurker on HN ever since I was a kid. I've seen over and over how HN is the most brusque & brutal online community.

But that's also why I love it. Taking every piece of feedback here to learn and improve in the future, and feeling grateful for the thousands of views my article is receiving!

Your article has been very well received, and it wasn't because that one line deceived people into paying attention, it's because the content is good.

I suppose it's not safe to assume that everyone started out like this. But advael is guilty of assuming that nobody started out like this. And on top of that, conveying it in a very negative and critical way. Don't get discouraged.

And, indeed, reading every file from top to bottom is very alien to me as a junior.

I would just try to get to the file I thought the change I needed was made and start trying and error. Definitely not checking the core files, much less creating a mental model of the architecture (the very concept of architecture would be alien to me then).

I would do get lost in irrelevant details (because I thought they were relevant), while completely missing the details that did matter.

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.

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.

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

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.

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.

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

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

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

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.

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.

"Remember your first day reading production code? Without any experience with handling mature codebases, you probably quickly get lost in the details".

Which looks pretty much accurate. And yes, this includes the (later) implied idea that many juniors would read a PR in some kind of linear order, or at least, not read it in order of importance, or don't know how to properly order their PR code reading. And yes, some just click in the order Github shows the changed files.

Not that for 99% of the industry, "junior dev" is not the same as something like:

"just out of uni person with 12+ years of experience programming since age 10, who built a couple of toy compilers before they were 16, graduated Stanford, and was recently hired at my FAANG team"

It's usually something bewteen that and the DailyWTF fare, often closer to the latter.

> Remember your first day reading production code? You probably did what I did - start at line 1, read every file top to bottom, get lost in the details.

I copied before refreshing, and sure enough that line was modified.

The range of (areas of) competence is just so damn vast in our industry that any discussion about the quality of generated code (or code reviews in this case) is doomed. There just isn't a stable, shared baseline for what quality looks like.

I mean really - how on earth can Jonny Startup, who spends his days slinging JS/TS to get his business launched in < a month[1], and Terrence PhD the database engineer, who writes simulation tested C++ for FoundationDB, possibly have a grounded discussion about code quality? Rarely do I see people declaring their priors.

Furthermore, the article is so bereft of detail and gushes so profusely about the success and virtues of their newly minted "senior level" AI that I can't help but wonder if they're selling something...

/rant

[1] Please don't read this as slight against Jonny Startup, his priorities are different

With all the money in the AI space these days, my prior probability for an article extolling the virtues of AI actually trying to sell something is rather high.

I just want a few good unbiased academic studies on the effects of various AI systems on things like delivery time (like are AI systems preventing IT projects from going overtime on a fat-tailed distribution? is it possible with AI to put end to the chapter of software engineering projects going disastrously overtime/overbudget?)

Conversely, if Terrence has only ever worked in high rigour environments, he's unlikely to understand Jonny's perspective when Jonny says that code generation tools are doing amazing "reliable" things.

Again, this isn't meant to be a value judgement against either Jonny or Terrence, more that they don't have shared context & understanding on what and how the other is building, and therefore are going to struggle to have a productive conversation about a magic blackbox that one thinks will take their job in 6 months.

If you want to dive all the way down that rabbit hole, can I recommend you check out the wikipedia article for the book Literate Programming [1] by Donald Kunth [2].

[1]: https://en.wikipedia.org/wiki/Literate_programming [2]: https://en.wikipedia.org/wiki/Donald_Knuth

Edited the post to improve clarity. Thanks for the writing tip!

Actually, the article shows that feed an AI with "structured" source code files instead of just "flat full set" files allow the LLM to give better insights

I think you're jumping ahead and missing a point that the article itself made: there are indeed bootcamp developers who were taught this way. I have spent quite a number of hours of my life trying to walk some prospective developers back from this mindset.

That said I think that you could write this entire article without dunking on junior developers and I don't consider it particularly well written, but that's a separate issue I guess.

But yea, having now read the whole thing I'm mostly taking issue with the writing style I guess. I find the method they tried interesting but it's worth noting that it's ultimately just another datapoint for the value of multi-scale analytic techniques when processing most complex data (Which is a great thing to have applied here, don't get me wrong)

Some of us have been around since before the concept of a “Pull Request” even existed.

Early in my career we used to print out code (on paper, not diffs) and read / have round table reviews in person! This was only like 2 decades ago, too!

It's only when a PR reaches a fairly high complexity (typically a refactoring, rather than a new feature) that I take the effort to sort it any further.

So, yeah, I guess I'm pleading guilty of doing that? But also, in my decades of experience, it works for me. I'm sure that there are other manners of reviewing, of course.