The Loop Inside the Editor

Editor feedback runs more often than every other loop combined. When it slows from instant to two seconds, nobody files a ticket — they just start ignoring it.

What runs here

Syntax and type checking, continuously.

Linting, on save or as you type.

Autocomplete and go-to-definition, which depend on an index.

Formatting, on save.

Test running, in editors that support it.

All of it depends on a language server holding a model of the codebase in memory, and that model is what degrades as the codebase grows.

How it degrades

Indexing time grows with codebase size, and a cold start becomes minutes.

Memory pressure causes the language server to drop or rebuild its index.

Generated code is indexed as though it were hand-written, frequently doubling the work for no benefit.

Large dependencies are indexed in full when only their interfaces are needed.

Multiple language servers compete for the same cores.

Formatting and linting on save add latency to the most frequent action a developer performs.

Diagnosing it

Ask. This loop has no telemetry by default, and five developers will describe the same problems.

Time a cold start: open the editor on the repository and measure until autocomplete works.

Time a save, with formatting and linting enabled.

Check what is being indexed. Most language servers can report it, and the answer usually includes directories that should be excluded.

Check memory allocation, which is frequently at a default set for a much smaller project.

Fixing it

Exclude what does not need indexing: build outputs, generated code, vendored dependencies, node modules, large fixtures. This is usually the single biggest win and takes minutes.

Raise the memory limit, which is frequently the entire problem.

Cache the index where the tool supports persistent indexing between sessions.

Move slow checks off the save path. Formatting on save is fine at fifty milliseconds and unbearable at eight hundred. A slow linter belongs on commit or in CI.

Reduce what runs on every keystroke to type checking; leave the rest to save or commit.

Check the project boundaries. A language server pointed at a whole monorepo when the developer works in one module is doing enormous unnecessary work.

The configuration problem

Editor settings live on individual machines, so one person's configuration fixes nothing for anyone else.

Check in what can be checked in: language server configuration, exclusion lists, formatter settings, recommended extensions.

Document the memory setting, because it is per-machine and cannot be checked in.

Include it in the setup script, so a new machine gets it without anyone knowing to ask.

Why it is worth the attention

It is the loop with the tightest attention coupling. A two-second delay in autocomplete does not break concentration the way a build does — it degrades the experience continuously, all day, in a way people stop noticing and never stop paying for.

It is also the cheapest to fix. An exclusion list and a memory setting are an afternoon, and the improvement is immediate and universal.

The exclusion list

The cheapest improvement in this entire collection and one of the largest.

Exclude from indexing: build outputs, generated code, vendored dependencies, package directories, large fixture files, coverage reports.

Check it into the repository so everyone gets it.

Verify by timing a cold start before and after.

Re-check when new generated directories appear, which they do.

Minutes of work, and it frequently transforms the loop developers spend most of their day in.

Checking in what can be checked in

Editor configuration lives on individual machines, so one person's fix helps nobody else.

Language server configuration and exclusion lists belong in the repository.

Formatter and linter settings, so output is identical for everyone.

Recommended extensions, where the editor supports declaring them.

Memory settings cannot be checked in — document them and put them in the setup script.

Without this, every developer discovers the same problems separately and solves them differently, which is drift by another name.