How to Increase Developer Velocity
Developer velocity is something that every engineering organization wants, but the steps aren't always clear on how to get it.
19 snippets of best engineering practices that help developers move faster.
Preview environments on pull requests.
One-click local deployment (through something like skaffold, docker-compose, or a bespoke tool).
Developers can deploy a significant part of the stack locally.
Inner loop (locally compile/deploy) feedback cycles < 5 seconds. For frontend toolchains (e.g., interpreted) should have hot-reload; for backend, optimized and cacheable builds. For small teams, that might mean an optimized BuildKit Dockerfile; for bigger teams, a reproducible build system.
Always release-able main branch.
Automated releases.
Reasonable full deploy time (rule of thumb: small teams, <15 minutes, large, <1 hour).
Standardized merge workflow (squash, merge, or rebase) that optimizes for either a linear commit history or one that retains feature branch context. This makes it easy (easier) to perform rollbacks.
No submodules. Balance of monorepos and microservices (U-shaped). When organizational debt exceeds technical debt.
Easy for developers to spin up their own infrastructure (developer accounts/staging environments).
Frozen packages, checked in or reproducibly defined.
Automated CI/CD pipeline (logs available, no bespoke instances).
Only a few different languages and stacks running production (no toolchain sprawl).
Monitoring and alerting (should scale with company size).
Limited third-party services (or open-sourced and debuggable ones).
An integration test suite that can be run locally.
Infrastructure defined as code that makes it trivial to spin up a new environment or make changes.
Code review culture. Ad hoc for small teams. For large teams, nearly everything gets code reviewed (see some things I look for).
High signal to noise on integration tests. Your Integration Tests are Too Long.