build-optimization

Build Optimization

Build speed and build correctness pull in the same direction far more often than people assume — a hermetic, well-cached build is both faster and more trustworthy than one that "works on my machine" via ambient state. The failure mode to design against isn't a slow build, it's a fast build that's fast because it's silently reusing something stale. Optimize in the order that preserves correctness first: eliminate unnecessary work, then cache what's safe to cache, then parallelize what's left.

A build that's fast and wrong costs more than a build that's slow and right, because the wrong one ships.

Speed up builds by doing less work and reusing verified work — never by skipping verification.

1. Make builds hermetic before you make them fast

A hermetic build depends only on declared inputs — no ambient environment variables, no network calls to unpinned resources, no reliance on whatever happens to be installed on the machine. Hermeticity is what makes caching and remote/distributed builds safe: if a build can produce different output on two machines with the same declared inputs, no caching strategy built on top of it is trustworthy, because you can't tell a legitimate cache hit from a stale one hiding a real difference.

• Declare every input explicitly — dependency versions, compiler flags, environment variables the build reads.
• No network access during the build step itself beyond fetching declared, pinned dependencies.
• Same inputs, same machine class, same output — verify this before trusting any cache built on top.

Done when: the same commit, built on two different machines, produces byte-identical (or content-hash-identical) output.

2. Build incrementally: only rebuild what changed

Full rebuilds on every change are the default in most naive setups and the single biggest source of wasted build time. Incremental build systems (Bazel, Turborepo, Nx, ccache, Go's build cache) track a dependency graph and only recompile the units affected by a given change. This matters most in monorepos, where a change to one package shouldn't trigger a rebuild-and-retest of forty unrelated ones.