News for hackers. Stuff that matters.
Re:Commit often, perfect later, publish once: Git best pract... by Retric on Sunday July 04, 2021 @10:44PM (#27734239)
I’ve read codebases that size, ~0.5m LOC is still generally a reasonable thing to read. With that kind of team and progress the majority of code is likely boilerplate. For example you can skim through most UI, ORM, and glue code only really looking for any abnormal parts of it.

The goal isn’t to understand every line, the goal is to have a basic map of what’s involved. Even a superficial read likely shows you what parts to emulate when you need some of that same boilerplate.

Time wise it’s a good substitute for reading HN etc whisk getting up to speed. Personally, I find it vaguely relaxing so it fills a similar role when you just can’t concentrate on the difficult side of things.

Re:Commit often, perfect later, publish once: Git best pract... by SergeAx on Monday July 05, 2021 @05:48PM (#27742134)
Reading hundreds of thousands LOC does not make any sense for me. When I finish reading I will completely forget what was in the beginning. Heck, I tend to forget my own code in just a couple of months.
Re:Commit often, perfect later, publish once: Git best pract... by Retric on Wednesday July 07, 2021 @11:20AM (#27762117)
It’s not about the low level details it’s what you discover durning the process and building a mental model of the project and the style the code was written in.

Also, memory isn’t just about unprompted recall. If in 8 months you’re looking for how the project generates PDF’s or whatever your not starting from scratch. Sure a full text search will probably bring up a bunch of files but skimming them a second time should look familiar. You may even remember that different sections of code are using two different 3rd party tools because that’s the kind of thing you notice an a first read but might otherwise cause all kinds of shenanigans.

Of course reading takes time, but it’s kind of like negative technical debt. Your prepping so anything else you want to do becomes faster. Asking coworkers about code before they jump ship can clarify stuff in minutes that might take days once they left. Even better you often learn something generally useful on other projects.