Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it
Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it
Aside: I don't understand the obsession people have with throwing out LOC. It's a completely meaningless number unless you're familiar with the codebase, in which case you don't need to be told the stats.
Agreed. A better metric is how much of it you need to interact with on a daily basis in order to perform any meaningful work.
If the code is sane, you'd only ever need to interact with and understand a fraction (a subset of the public APIs) of the entire codebase. You could have millions of lines of code and be productive when knowing only a couple of hundred of those.
If the code is insane, the risk is that you'd need to interact with most of it when introducing any non-trivial functionality. Worst case scenario there isn't any clear rules of what is public and supposed to be used, and what is private and isn't supposed to be used, and people have used "whatever from where ever" to solve their problems.
The second one is always bad, but also significantly worse the more lines of code there are. Perhaps those who throw LOCs around also implicitly tell us that they are dealing with the second variety of code.
LOC is the metric I get to remain employed or fired on.
Answer could well be yes since build time impacts everyone, but also have to factor in complexity of the CI system they use.
Long build times are an operational risk - it's very hard to apply patches to solve incidents with a 20 minute build time.
Because THAT'S the hard problem to solve in any bigger organization. Not hacking the code.
Maybe, or just a knowledgable person to dig in for a bit and solve it. On one of my teams when I was back at Microsoft was working on a similarly huge codebase with build times twice as long. We had a senior engineer who was really into build optimizations from a previous job who wrote a tech design, implemented better project splitting in our monorepo, better local caching, and finally cloud caching, all within 3 months. When I left, our builds ranged from 30 seconds to 3 minutes.
It's not guaranteed that it'll be this simple, but I also don't think it's guaranteed it'll be 3 years and several people.
I agree though, definitely a factor
This is why build systems like buck/pants/bazel are good in larger codebases. You can trust your incremental builds in a way that you can't in any build system that isn't hermetic.