Nowadays, it is pretty much impossible to get involved with a project without hearing about "being more agile." And even though I have been on a variety of projects of various agile flavors, one term that I've heard consistently is the team's "velocity."
For those who aren't as familiar with agile projects, velocity at its core can be defined as the number of tickets (i.e., work) that an individual or team can complete in a sprint (i.e., a set amount of time). To no one's surprise, the general sentiment is that the more work you can get done in the allotted time frame is a good thing.
With that premise in mind, it doesn't take much for someone to come to the simple conclusion that one's value as a developer is dependent on how many tickets you can close. I was no exception to this. However, I have recently taken it upon myself to finally journey into the often forgotten realm of test driven development (TDD). And as luck would have it, my entire perspective was about to be flipped upside down by Eric Elliot.
Contrary to the popular definition of velocity, Eric argues that velocity for a developer should not be measured by how many tickets a developer can close. In fact, he thinks that it is "absolutely ridiculous." Instead, he proposes that velocity "is a measure of [the] team's ability to adapt and ability to add or remove things from the app quickly."
When I first heard him utter these words, I had to pause the lecture because I was just appalled at how flawed my thinking was all this time. And don't get me wrong, it's not that I really thought that more closed tickets meant I was somehow faster as a developer. In fact, from my experience, more tickets closed out without regard for solid practices like TDD actually produce technical debt for the future developer to deal with (i.e., future me).
More on this in due time as I grapple with this new perspective on velocity and how it impacts my workflow as a developer...