Development Environments

  • A high quality dev environment is sound. Any success locally should never fail in CI. But local failure is allowed to pass in CI (although it should be minimized)
  • A high quality dev environment shares many properties of CI/CD
    • Sound
    • Quick cold startup
    • Caching
    • Ergonomic to have automatic actions
    • Properties of good CI/CD test suites also apply
  • A high quality dev environment has many automatic actions and properties. The general principle is to reduce cognitive load whenever possible by automating error prone tasks and eliminating micro context switches. This is often accomplished with a combination of editor integrations, git hooks and other state/workflow triggers, and file watching
    • Automatic formatting, linting, type checking. Auto run test-suite locally if type checking passes.
    • Use git hooks to enforce code style conventions, lint for code smells, enforce branch naming conventions, commit naming conventions, changelog generation, etc.
      • Do not use git hooks to prevent people from pushing if the test suite fails. Only prevent push on things that are both sound+complete (eg, checking a branch name convention)
    • Use direnv and other env solutions to setup: paths for local helper scripts, ergonomically enforce a consistent developer environment, etc.
      • Docker containers can work well as long as they don’t bloat up into a slow cold boot
  • A high quality dev environment takes care to manage state and caching in an effective way
    • Whenever possible, preserve state across changes (warm reloading)
    • Ideally, automatically load preserved state after changes (hot reloading)
    • Rebooting a dev environment should not take multiple error prone steps
    • Branch switching should not be an error prone and tedious process
    • Branch switching should not introduce stale state that can cause soundness to fail (eg: purposely breaking tests after switching branches does not cause them to fail)


Links to this page