I've often written about developer velocity, but haven't formally defined it. In general, velocity is speed with direction. So I think of it like this:

Developer velocity is a measure of productivity related the rate of software changes.

Developer velocity isn't the whole of developer productivity. I think of developer velocity as post-commit workflow. Once a feature or change set is ready, how much "red tape" is there to get those changes out to customers? But "red tape" isn't just bureaucratic with software.

• How fast can changes go from development to production? Most organizations don't have a continuous or automated pipeline, so a corollary to this is how often changes are deployed.
• How often do changes fail? There's never true parity between development and production. It's why even in organizations with the most advanced tooling, you still see outages due to tough-to-test changes like BGP routing (see Meta). Flaky tests, flaky deploys, and bad deploys all create friction that works against developer velocity.
• How fast does it take to reach desired state? Rolling back changes, patching security vulnerabilities, recreating environments? Even in automated systems, full build and deployment times can wildly vary. A build that takes an hour (like recompiling a Linux kernel) can make a deployment cycle frustratingly long. Longer loops mean less feedback for developers.