Contact Us

Programmer Productivity: Measuring Results

Posted on 13/8/10 by Felix Geisendörfer

This is post #2 of my programmer productivity series.

Before I embark on trying out various productivity strategies, I need to establish a set of metrics that will help me understand what works, and what doesn't.

For now I decided to keep track of two things:

  1. My time, using a daily journal where I enter every task I am working on, and the time spent on it.
  2. My commits, as well as the lines of code I add / delete throughout my day

If you want to follow along, I am using a simple notebook for my time tracking. I write one task per row, using the following format:

  • 09:23 - 09:26 Coffee & Planning today's tasks (3m)
  • 09:26 - 10:30 Work on setting up new server (1h 3m)

By writing out the time I start and end my tasks, it's pretty hard to miss an item.

As far as commits are concerned, I whipped up a simple node.js script that you can download here. To use the script, copy it anywhere on your machine (maybe you like /usr/local/bin/gitloc ?), and then add it to your git post-commit template hook like so:

$ cat /usr/local/git/share/git-core/templates/hooks/post-commit

This will automatically track the commits in all new repositories you create. If you want to track an existing repository as well, simply do "git init" in the projects root directory, and the template hook will be copied in.

The CSV file created by the script looks like this:

2010-08-12 17:00:09,8eb212e,Implemented initial map display,142,130,/Library/WebServer/Documents/tvype/portal
2010-08-12 18:34:22,1fa8859,Initial billing code,86,2,/Library/WebServer/Documents/

The columns after the commit subject are the lines added / removed. The last column is the path of the project the commit was made to.


As far as evaluating my time spent, I have come up with a simple system of classifying my task log entries into three categories:

  1. Productive work: I'm creating value for other people (clients, transloadit customers, etc.). If I did this all day, I'll reach all of my goals.
  2. Busy work: Answering emails, meetings, staring at the screen with little results, fixing bugs, even writing this blog post series (It's not productive work unless I'll make a living selling productivity advice, which I won't). If I did this all day, I'll end up getting very average results.
  3. Procrastination: Reading news, lunch (if longer than 30 min), checking emails in an unproductive way, playing games. If I did this all day I'd be homeless in no time : ).

Of course the lines are always a bit blurry. My advice is to assign a task the category you intuitively think of first. If you must, split the task up in 50% of each category. Skip to the bottom of this article to see my summary for yesterday.

Regarding the commit log, for now I'll simply count:

  1. Lines added
  2. Lines removed
  3. Projects worked on

Ideally I will strike a balance here. Never < 100 lines / day, but >= 1000 is way too much as well. This might be a "programmer productivity" series, but many of us have other tasks that would definitely get neglected if we only wrote code all day.

Yesterday's Productivity

And here comes the promised analysis from yesterdays logs:

  1. Productive work: 4,03 h
  2. Busy work: 4,60 h
  3. Procrastination: 0,45 h

Time after 6pm: 1.5.h

274 lines of code added, 186 deleted in 3 projects

A few thoughts on those numbers:

  • There was a 2.5 hour meeting with our client yesterday. That's the first time we had a meeting that long and hopefully the last time ; )
  • I won't add "Procrastination" that happens after 6pm to the numbers. If I choose to work after 6pm, fine, but if I like to play instead that's cool. There is no reward for burning out.
  • The 0,45 h procrastination are from a SC2 game I played with Tim after lunch. Damn you Blizzard ... . There was also 5 minutes of unproductive email checking / following a link to Facebook.

Coming next

My next post will look into productivity killing patterns and habits and how to fight them.

I won't start setting specific goals until I have collected a little more data about my current productivity.


PS: My friend Mark Grabanski wrote a post on various productivity factors. Good thoughts, especially on the importance of "tools".


You can skip to the end and add a comment.

Anthony said on Aug 13, 2010:


Great post (and series of posts, for that matter). It's heavily focused on programming, but what it really all comes down to is basic time management, whether or not your end goal is to be a better programmer or better [insert-anything-else-here].

I find that the most important thing I can possibly do to remain productive is set my schedule the night before so that once you wake up, you know exactly what you're supposed to be doing. I plan down to the minute - even including when I will eat. I am only reading & responded to this post right now because it's my "lunch and Google Reader" time, you see? This strategy really helps me understand the importance of time. If something comes up, I have to ask myself - "is this really more important than the time commitments I've already made?". And almost always, the answer is "no". Without setting a strict schedule, procrastination & non-priority tasks seem to enter the fray much more frequently.

I have a couple posts on my own blog with my thoughts on time management. Check em out if you're interested:

Tijs Teulings said on Aug 14, 2010:

Hi Felix,

While this sort of time tracking is very useful and probably a good start on the way to ultimate productivity ;) I do find that programmers have a tendency to get a bit too obsessive over the details. While data is good productivity is mostly about the big picture. If you end up spending all your time logging your still not being productive..

So some tips you may or may not want to keep in mind:

- stop keeping minute by minute logs, focus on the big chunks instead
- log by half hour increments, how many minutes you spend drinking coffee is irrelevant. You need to know which client (internal or external) you spent time on, the project you were working on and maybe the 'module' i.e. OAuth integration.

- the number of lines you've written is not a good measure of productivity. I would suggest making a seat of the pants hours estimate for each project and component of that project and then check afterwards if you got close. If you were faster you were productive if you didn't you can analyze why: distraction, wrong estimate, more difficult problem, etc.

- procastrination is not evil, you don't need to get to 8, 10 or more coding hours every day. Sometimes a little zoning out is good so you can start fresh later. Obviously spending your procastrination time walking around the block is beter than clicking on links in Facebook :)

Just my two cents...

Felix Geisendörfer said on Aug 14, 2010:


I've actually tried to work that way a few times in the past. But I always ended up very frustrated because certain things did require me to reschedule frequently. That being said, I agree that the results can be amazing, so I will consider giving it a try again.


I'm not obsessing over every minute. I don't log going to the toilet, short incoming calls and stuff like that. Over the past 2 days I've been looking 15 / 17 tasks a day total.

I agree with with you on the lines of code. They do not measure productivity directly, but they do measure "effort". That, and your bug-rate is also proportional to them, so they are an interesting metric that helps with my productivity analysis. I do like the idea of working with more estimates and analyzing the resulting outcome, I will start doing that.

Procrastination is evil. I don't mind spending 30 minutes a day walking, meditating or playing SC2 / foosball, but beyond that it's wasting time rather than refreshing.

Sonic  said on Aug 17, 2010:

Hi Felix,

Really glad you're doing another 30 Day blog session. I'm actually trying to sort out my own productivity at the moment. One very small thing though, Shouldn't
# Busy work: 4,60 h be 5 h?

I may be wrong but was confused by your notation. I tried looking up German notation in Google/wiki in case you meant 4hrs 36mins but it wasn't clear. I'm just saying this for your own analysis, if you're were adding the times up automatically.

Very much looking forward to the upcoming posts ;)


Felix Geisendörfer said on Aug 17, 2010:

Sonic: 4,6 h means 4 hours 36 minutes (.6 * 60 = 36). I'm using that notation because the spreadsheet I'm doing this in doesn't want to print it any more readable for me : ).

This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.