[Aeolun]

> Unfortunately, 17min to build is pretty good.

My biggest pet peeve with this is that a lot of people see these values as immutable, and because building/testing/running every single push takes too long, we should not do that.

As opposed to making builds faster, or build infra faster/cheaper.

[zaphar]

There are mostly only a few ways to make builds faster.

* Ship less code (Very hard to get a large org to do)

* Rebuild the same things less often. Requires using build tooling that supports this org wide, Still hard to do but not as hard as shipping less code.

* Build more pieces in parallel. Also requires using build tooling that supports it org wide as well as structuring the code in such a way that it is amenable to parallel building.

These are all expensive investments that will pay off huge if you do them but can be quite difficult to justify until you reach a certain size.

[recroad]

Can you expand on "ship less code"? I think I'm agreeing with you but I'm taking it to mean ship smaller pieces of code, not overall LoC.

[zaphar]

I mean both. Smaller pieces but also less of those pieces. It is my experience that many systems code size is less purely a function of what they need to do than a complex set of layered components and systems in the name of ease and fear of NIH syndrome.

Sometimes doing the same thing with simpler components and fewer components is just better.

[Aeolun]

These kind of speedups at LinkedIn scale all fall off the chart at the bottom left of this scale:

https://xkcd.com/1205/

Nonetheless, leadership will never give it priority.

[cbb330]

The top 1/3rd of Eng don’t see it as immutable. But the stack can consist of 10 other teams tools, and you’re not rewarded for the amount of time you’re spending to fix other people’s stuff. So it goes on