3 ms·

Let's take exactly 10 engineers and let them work on the project for exactly 5 years. That would be roughly 2500 mythical man-months. Let's say 2000 due to vaca

Let's take exactly 10 engineers and let them work on the project for exactly 5 years. That would be roughly 2500 mythical man-months. Let's say 2000 due to vacations, holidays, non-coding tasks, other tasks and Googlesque 20% pet project time. Let's say every engineer produces 100 lines of code including blanks and comments per day and deletes another 50. This is anecdotal, you may check your own numbers. This is +250 LOC per week and for our team it means that entire codebase will be 0.5m LOC in 5 years. I saw a codebase this size once. In 2 years I've read about 1/10 of it.

Retric 5y ago
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.
- SergeAx 5y ago
  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.
  - Retric 5y ago
    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.

Retric 5y ago

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.

SergeAx 5y ago
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.
- Retric 5y ago
  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.