Recently I started optimizing my workflow with various scripts and tools. I measured my performance and found it increased a lot.

Some people asked to see stats behind the story so here they are, calculated retrospectively from log files for 5 months before the change and 5 months after it.

4x more productive overnight

I’ve been tracking 3 easy-to-measure metrics:

1. Bugs fixed
2. Change sets committed
3. Number of functions changed

For your viewing pleasure and mine, I’ve tweaked my script to render graphs with the GChartWrapper python module:

I started trying to improve my own performance sometime in mid-January; unfortunately I didn’t keep track of the exact date.

The data are scaled to show bugs fixed per man-month rather than calendar month; from February onward I’ve been in parental leave (Germany’s extremely generous Elternzeit to be precise) and have been working exactly half-time at 18 hours a week.

As a rough measure, let’s compare my performance in Aug-Dec to that in Jan-May, ignoring the fact that I started this scheme mid-way through January and not at the start of the month.

Performance boost: 55.4 / 9.4 = 5.9 times more productive

A changeset can be anything from a bug that was too minor to both putting through the bug-tracking system (such as a message box typo) or a little tweak or extra feature added in passing. Static analysis tends to throw up lots of small fixes that I address with direct commits, for example.

Performance boost: 100.4 / 28.0 = 3.6 times more productive

I started tracking functions changed just out of curiosity; the numbers of tickets fixed and changes committed are open to various levels of manipulation - I thought the total number of functions touched by a change would be an interesting check to make sure I wasn’t just solving all the easiest tickets or committing lots of tiny, pointless changes.

Performance boost: 344.8 / 85.6 = 4.03 times more productive

Hey, is that awesome?

Nothing about the above measurements or calculations is perfect; simply ignoring December artificially depresses the performance boost, as does treating all of January as the post-boost phase. On the other hand it seems incredibly unlikely that working half-time is exactly half as productive as working full-time.

We could argue that the email and communications burden remains the same when working part-time, so we’d expect less the time to be available for productive efforts. Or on the other hand that most of a full working day is wasted anyway.

We could argue a lot of things, but none of these concerns can account for a 400% increase in productivity.

Not only that, but the number of bugs fixes (5.9 times increase) - is a metric of real value to our company. Generally our software director chooses the set of bugs to be fixed for each release and gives them priorities, which means all those bugs had to be fixed and I wasn’t at liberty to pick all the easy ones.

I do like fixing the easy ones, though.

Whether my measured productivity has doubled or increased ten-fold is really neither here nor there; even just doubling your productivity by any set of measurements over a sustained period of five months is incredible.

I’ve also been a lot happier, which is like winning twice.

Wait! There are 3 reasons not to do this!

“I changed my editor bindings, and now I’m a super-hero coding monster. Also, my breath cures cancer. Hooray for Command-T!”

I’m tired of posts like this too.

I want to make something clear: there are really good reasons that you can’t write a commit script, track your performance and expect it to quadruple. There are good reasons not to even try:

Reason #1: I was intrinsically motivated; that’s why it worked

In psychology and the study of education it’s well-known that intrinsic motivation is everything in learning and self-improvement. I already yearned to improve my own effectiveness, that’s why I started doing this. It fascinates me, it calls to me. That’s why it worked.

If you already long deeply to improve yourself, you will do with or without my advice. If you don’t, then drawing little graphs won’t help either. There’s no reason to believe that blindly going through the same motions I did will produce the same result for anyone else.

Your motivations can and do change over time though and maybe reading this will help to motivate you too - I hope so!

Reason #2: never replace intrinsic with extrinsic motivation

It turns out that offering employees bonuses or performance-related pay can be harmful. In some cases - such as programming - an external motivation, such as a bonus, produces measurably worse performance than an internal motivation, such as the love of coding.

Worse still, such an extrinsic motivation will often replace an intrinsic one, damaging performance and job satisfaction.

If you start measuring your performance, you may end up replacing your intrinsic motivation to do a great job with an extrinsic one to make the numbers go higher.

If you start measuring other people’s performance, you certainly will.

Be very, very careful.

Reason #3: these stats don’t measure programming excellence

So, should I ask for a 400% pay rise now? Am I four times as valuable to the company than I was last year?

No and no. I like to think I’m somewhat more valuable to the company now, but not by a factor of two, let alone four! You see. these stats don’t encompass everything a programmer has to do to produce awesome software; they don’t actually try to - they have another purpose.

It’s like running and football: professional players care about how fast they can run 50m. They even practice sprinting during training. It has some value to them. Yet if you ranked all professional football players by how quickly they can run 50m, you wouldn’t find all the top players at the top.

How would a football team composed entirely of olympic sprinters fare? Exactly. Running fast is one tiny part of playing football. Resolving bugs efficiently is one tiny part of writing excellent software.

Stats such as these are useful for your own training, for measuring and improving one specific aspect of your competence but they are worthless other purposes. Don’t use them for:

1. Comparing developers to each other
2. Measuring or motivating a team
3. Hiring new people

It should be clear that single-figure statistics are useless for these goals, but people love graphs and they love putting numbers on things so I’ll state this as clearly as I can:

It doesn’t matter how many bugs you fix per month if your code sucks and the UI looks like a Fukushima control panel after the explosion.

The bottom line is that you can use these stats to measure your own performance increases, but once your goal becomes to increase the stats, you’ve already lost.

Good luck!

Postscript: If you’re interested in seeing my sorry collection of hacked-together python and bash scripts, leave a comment to that effect and I’ll put together a “Metagame: Nasty Hack-Filled Scripts” post for you with all the sources. I’m happy to talk about this on twitter, too.

Edit: Here’s a link to the HN discussion and the Reddit thread for this post.