We all like to assume that the applications we work on are getting better each and every time we sit down in front of the IDE and start banging out code for it. But how do you really know? Code metrics help with that. You can see how coupled your classes are, the cyclomatic complexity, and that sort of thing. As you go, you can look at the historical stats vs the current stats and (hopefully) see an improvement, which suggests greater maintainability down the line. Great.

But what about personal metrics…?

Despite how quickly technologies change, it’s easy to grow complacent and for skills to stagnate.

So how do we detect these weak spots and build up our resilience and proficiency in our skills?

In a team setting, I’ve helped increase our collective skills by implementing what I’ve called “Developer Fight Club”. It might be a simple algorithm or a full-fledged application, but the end result is someone will be deemed the winner and the rest of the participants are able to learn from their mistakes (or the successes of others) in order to perform better next time.

On a personal level, though, it feels a bit more difficult… Over the years, I’ve used all sorts of goals and metrics. Number of tickets closed, average duration between work-order assignment and resolution, frequency of blog posts on this site, number of development books I’ve read each month, etc.

There are definitely large gaps and flaws in the information you can get from any one of those values, but I think if they are looked at collectively, it can at least give me a more objective look at how engaged I am, more than I might be aware of on my own.

And, really, that’s what I think has the most impact for me. If I’m fully engaged in my development work, I naturally will want to put in the extra effort. Conversely, even if I’m learning new technologies or applying new methodologies, I won’t get much out of it if I’m just going through the motions…