In this enlightening article from the New York Times, Charlotte Graham-McLay reports about a company from New Zealand that tried something out. They switched all their employees to work only 32 hours per week instead of the regular 40 hours. All of them still received the same salary for 40 hours though. What they found was that their productivity increased and the employees got the same amount or work done. Sometimes even more. To reach this level of productivity, they reduced meeting times, didn’t leave early or took longer breaks.

This experiment was studied by two researchers, one of them said:

They worked out where they were wasting time and worked smarter, not harder […]

There are so many interesting takeaways from this article. I will definitely come back to it and talk about topics like billing time for work done (a topic of interest to me as I am working as a freelancer since January) and finding motivation and smart-working.

For today I would like to think about the topic productivity. How can I do more work in less time? My wife will give birth to our second child in a few days. As a result I will reduce my billable time by quite a lot, to have more time available to spend with the family. Still I want to be able to charge my clients enough money so I do not experience a drastic cut in revenue. So this makes me look for ways how I can be more productive. If you want to improve some condition, you need to measure it. Otherwise you don’t have any way to find out which actions improve your condition and which worsen it. So now the question is: How do you measure your productivity, when you are writing code, creating features, delivering software (pieces) to your client? One simple, almost obvious, measure might be how much you code. So this could be the lines of code, that you are producing. I feel like this might be a delusive metric though. I like brevity. I do not favour brevity over explicitness/clarity, but I try to write less code. In the sense of coding smarter, not harder. Equaling more code with more productivity makes no sense for me in that way.

I also like to commit early and often. My commits are usually small and concise. In so far it could be a metric to count my commits. Now I think I could increase my productivity by committing even more. Without changing anything else! It would also put others in a bad situation, if they just happen to commit less, with bigger commits. Regardless of whether I’d like that way of committing, they would appear to be less productive than me, even if the weren’t. I guess counting commits does not make any sense then, for me.

Then I thought of another metric: The number of opened pull requests. I believe, now we are getting somewhere. Every open pull request tries to improve the status quo of the software. It could be a new feature, or just an addition. It could be bugfixes. It would be work-in-progress branches or just spike solutions where things are tried out. But every new pull request you open shows that you did real work, for the benefit of the project. So I do hope your team is doing pull requests, and I do hope you have a good review process. Because I think this really is a nice metric of productivity. Perhaps we should only count merged pull requests, not opened pull requests? Because a merged PR shows that your changes were accepted and really brought the project forward.

I do not have a better metric to measure my productivity than merged pull requests. I think it’s still not the perfect metric—what happens if your team partners are on vacation, or sick and the review process hangs? This makes your PRs stale… But this metric will be the one I’ll keep an eye on during the next few weeks. For now I’ll just count the PRs by hand and keep track of them in a spreadsheet. If it turns out to work well enough for me, I might use GitHub’s API to automate that.

Please tell me about your metrics. How would you track your productivity? Perhaps you already do?

Holger