Table of contents
Open Table of contents
A lesson on kinematics
- Displacement: the distance between two points in space
- How far is point A from point B?
- You are here and want to go over there, which is 60 miles away.
- Velocity: the rate of change in displacement
- How fast are you going from point A to point B?
- If you go at 60 miles per hour, you will get there in 60 minutes.
- Acceleration: the rate of change in velocity
- How fast are you speeding up or slowing down to achieve the desired speed?
- You start at 0 mph and need to get to 60 mph; you will then need to end at 0 mph.
- Jerk: the rate of change in acceleration
- How abruptly are you speeding up or slowing down to reach the desired acceleration?
- You put the pedal to the metal, then the other pedal to the metal.
- And for the mathematically inclined folks:
- Jerk is a derivative of acceleration
- Acceleration is a derivative of velocity
- Velocity is a derivative of displacement
*LLM-assisted content - my dear reader, you can’t expect me to remember stuff from Physics 1
A macro application of theory
In the world of software development, there is a concept of developmental velocity, which is a metric for work done by a software development team 1.
Simply put, it’s a measure of progress between two arbitrary points. During this week, or sprint, or quarter…how many bugs did we fix, or new features did we deploy? How many PR requests did we close? How many story points did we accomplish this sprint? How many shirts did we fold?
Then, deriving from the velocity, we can get a team’s developmental acceleration - having concise standups, setting up great CI/CD, or using LLM-assisted IDEs/PR bots. Processes that are net productivity boosts for the members of the team. And chances are, if you have a great developmental acceleration idea, YC will throw at least one wad of cash at you.
Finally, to complete this analogy, a developmental jerk would be a project manager. Or the firing/hiring of one - otherwise, they’re usually singular events that compound to alter a team’s everyday developmental acceleration.
The business translation
Sadly, developers work for businesses, and in the business context - a development team is the same as any other business unit and is therefore measured by how much value they ultimately deliver. The problem is that the ratio between work done and value delivered is pretty much never 1:1.
A development team usually won’t care about the dollar amount feature X will bring in.
An executive won’t give two shits how much work, or if it’s even possible, for feature X to be built. They just want it to exist.
And this, I think, is usually the biggest point of contention between technical and non-technical folks, and the reason why certain roles in the industry exist. That being said, I think that the translation from work output to business value is a very understated skill; those that have it are usually very good at what they do - and a positive credit to dev teams.
Those that don’t have it? They’re usually a negative jerk.
Under the micro scope
Anecdotally, I feel like there are a lot of developers (myself included) who would spend hours or even days automating a certain task, just so we won’t need to consciously execute it at a present moment. For example, I set up a VS Code workspace just so opening up my IDE would automatically run yarn dev for this site. If we want to bring a physics analogy back into the mix, we developers love to remove friction by front-loading the cost - use brain power now so you don’t need to later. Tangentially related. Our engineer brains always seem to stray towards the removal of negative jerk and not the addition of positive jerk.
For you or me, developmental kinematics just don’t mean the same thing as they do in a corporate connotation. After all, we live in the today, operate on the now, and we’re only responsible for ourselves. Feature X’s timeline is in two weeks, but what am I doing at 3 PM today?
And just like how it is in the macro, the little things are what compound to make you an efficient worker. You may have learned more frameworks and paradigms - doing more with less as you climb the title ladder - but at the end of the day, knowing how to best optimize how you work is still the most efficient way to get the most out of you.
An object in motion stays in motion, so make sure you’re not coming to a stop.
And obviously, there’s more to life than software development…
Parting thoughts
I use Wikipedia as a credible source - mostly for definitions.
I also use dashes a fair amount, not of the em variety, and I refuse to change. I was doing it before it was cool.