The "ten hours a week" framing needs a caveat before anything else. Format-on-save does not save ten hours; it saves maybe twenty minutes and removes a category of argument. The real hours come from three places: not losing half a day to a broken local environment, not context-switching to a terminal forty times an hour, and not spending review cycles on things a machine decides. Automate those and the number is plausible. Automate keystrokes alone and it is not.
The failure mode is not "nobody formats", it is "everybody formats differently", so each save rewrites a file someone else just rewrote. Three files fix it, and all three belong in the repository rather than in your personal settings. .editorconfig handles indentation, final newline and charset for every editor, including the ones your colleagues use. A pinned formatter in devDependencies means CI and laptops agree on version. A committed .vscode/settings.json makes it automatic:
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" },
"files.trimTrailingWhitespace": true
}Add .vscode/extensions.json with the recommended extensions so a new hire gets the prompt instead of a wiki page nobody reads.
A hook that runs the whole test suite gets bypassed with --no-verify within a week, and then you have no hook. The rule is: hooks touch only staged files and finish before you notice. In JavaScript that is husky plus lint-staged; in polyglot repos the pre-commit framework covers Python, YAML, Terraform and shell from one config, and installs its own tool versions so it behaves the same on every machine. Put fast, deterministic checks in the hook (formatting, trailing whitespace, large-file detection, secret scanning) and everything slow in CI. Keep the escape hatch working deliberately; a hook you cannot skip during an incident is a liability.
The habit that costs the most time is alt-tabbing to a terminal to re-run something you always re-run. Pick a watcher and stop:
watchexec -e ts,tsx -- npm test -- --bail for a general-purpose, language-agnostic loop.fd -e py | entr -c pytest -x when you want the minimal, dependency-free version. The -c clears the screen so you only ever read the current result..vscode/tasks.json entry with a problemMatcher, so compiler errors land in the Problems panel as clickable lines instead of scrolling past in a terminal. Mark it as the default build task and it is one keystroke.Pair this with a Makefile exposing make dev, make test and make fmt. The point is not Make; it is that the entry points never change even when the tooling underneath does, so your editor tasks, your CI and your README all call the same three commands.
Rename symbol (F2) does a project-wide, syntax-aware rename that find-and-replace gets wrong on substrings. Quick fix (Ctrl+.) writes the import, adds the missing case, and extracts the function. Multi-cursor via Ctrl+D on repeated tokens beats a regex for anything you can see on screen. Go to symbol in workspace (Ctrl+T) is faster than remembering which file a function lives in. In the shell, bind history search to Ctrl+R with fzf and stop retyping long commands, and learn !$ for the last argument of the previous line. Snippets earn their keep only for genuinely repetitive scaffolding, with tabstops for the parts that vary; a snippet for something you type twice a month is net negative.
This is where the hours hide. Keep dotfiles in a repository and symlink them with GNU stow so a new laptop is a clone plus one command. Pin toolchain versions per project with mise or asdf so switching branches switches Node and Python versions automatically instead of failing mysteriously. Ship a .devcontainer/devcontainer.json so the answer to "it works on my machine" is a container rebuild rather than a two-hour debugging session with a colleague. The first time this saves someone's onboarding day, it has paid for the afternoon it took.
Some honest limits. A hook that fails intermittently burns more time than it ever saved, so delete flaky automation rather than tolerating it. Auto-fixing lint rules on save can quietly rewrite logic when the rule is not purely stylistic; restrict fixAll to the rule sets you trust. Auto-organising imports on save produces noisy diffs unless the whole team does it. And a heavily customised editor is a skill that does not transfer to pair programming, production shells, or the next job. The automation worth keeping is the kind that lives in the repository, where it works for everyone, not the kind that lives only in your home directory. If you are still choosing an editor to build this on, the code editors roundup compares the current field.