If you read my blog regularly, you’d recall that I can be quite obsessive over my productivity. I religiously track my productivity in a variety of metrics and tools – I have a premium account at RescueTime; I use Github to track the commit quantity and quality.
Yesterday was a very good day. The above screenshot shows the RescueTime dashboard report for the day. I had spent 89% of my tracked time on productive stuff. My Github records concur. Yesterday was a good day. I committed 14 commits to my project, and git diff --stat showed in total I wrote 1703 Lines of Code, and deleted 699 Lines of Code.
By comparison, according to RescueTime’s trivia bar, yesterday I was 20% more productive than my usual productivity pulse of 74. I also only usually manage to make one commit at about 200 LoC addition per day to my projects.
I was in short, on a roll. So how did I get so productive? This entire week has been rather productive for me. I believe I may have discovered what works for me when engaging in non-creative work.
The Tricks To Get Productive
The trick that works for me is to work late at night: Note that I sleep at about 4 a.m yesterday, and woke up about 8.30 and started work at about 9. There is a certain serenity to be found when working at 2 in the morning. The second trick that works for me is that I leave the problems of medium difficulty partially solved when going to bed. That way when I wake up I have answers (or at least vague notions of how to fix the problems), and then I tackle it the first thing in the morning. Lastly, before going to bed, I leave myself a TO DO list as I go along. Mine is as simple as leaving //TODO comments in the code. I also practiced polyphasic sleep. I took a 45 minute nap between 12 and 3 yesterday.
But…
There is a caveat though. I think this only applies to non-creative work. The main reason why I was so productive this week was because my to-do list for the week basically consisted of me writing tests. Writing tests is a tedious, repetitive and really non-creative task. A trained monkey can write tests. There aren’t any particular challenge to solve. Heck, at one point I got so bored I actually wrote a script to generate my tests for me – it didn’t really go so well though.
This is the problem with all the productivity metrics and productivity porn afficionados out there. They apply mostly to a 1950s manufacturing mindset of productivity, where work is all equal from all peoples. It was most certainly true: A worker who can rivet 10 rivets an hour is more productive than a worker who can only rivet 2 rivets an hour. Workers are kinda fungible in that sense.
But not all work are equal. When I was working for someone else, a lot of my work involved problem solving and creating new things. From my working experience, I can say that some of my best work will get me fired if I weren’t working in a more liberal company. The reason is this: I look like I’m staring into space for 8 whole hours, and doodling on papers, while actively ignoring email when I’m in the “problem solving zone”.
Advocates of agile, lean or even extreme programming methodologies are often very obsessed with productivity. Terms like ‘velocity’ are thrown about. In my opinion they’re as broken and stupid as using Lines of Code as a metric of productivity used in the late 70s (where programmers were paid per line of code), or number of commits per day* Yes, I track both and intentionally mentioned both above, to make a point. . This applies not only to programming, but most knowledge-based working such as research and development. It’s just that it’s easier to track and create metrics while writing software.
Track the Soft Metrics
Certainly there are very clever people who are solving the problem of tracking productivity in a knowledge worker. One of the options to track productivity is to use soft metrics, instead of hard ones like commit count or LoC. One that I really like is iDoneThis. In Google, snippets are used in some teams as well, and I like that concept as well. Even RescueTime’s time tracking method is not half-bad.
The problem with soft metrics is well, it’s soft. It’s difficult to quantify, and more often than not, difficult to qualify as well. Another problem with using a goal-based metric, such as Snippets is that users have the incentives to set the bar lower, as to then exceed expectation.
Track What’s Thrown Away
I have a different idea though.
I have found that I’ve often doodled on paper, or wrote proofs-of-concepts scripts and throw them away as I’m in the process of solving a problem. I also read a lot on the problem from various sources. I occasionally make throwaway notes. I think that may be a key to tracking productivity. In fact starting this week I’ve started tracking my throwaways and readings. I’m curious to see where it goes.
The prevailing idea is to track what is thrown away then mine said data for learning.
Another idea is to track waste ala the lean methodology. For example, from 9pm to 1am last night I was on the computer, but RescueTime showed nothing in the screenshot above. The reason? I had to fix my computer from a stupid Ubuntu update. Somehow fglrx had failed/got corrupted/whatever and my computer wouldn’t boot. I spent nearly 5 hours debugging and fixing the computer.
Is this a waste? Yes, but how does one quantify this? If I don’t fix the machine, I would waste even more time by not doing any work on my project, so from a certain point of view, it wasn’t a waste. But at the same time, I’m not adding any more things to my project. These things I think, are worthy of figuring out.
What do you think is a good way to track productivity?