A bunch of websites and tech evangalists have been talking in the last few months about how bad working too much is. Not just ‘hey, it’s not good for your health’ bad, but ‘it’s not good for your codebase’ bad. For the past 3-4 years, that has been one of my pet peeves, and it’s awesome to hear other people get onboard. Matt Rogish has a good graph (cc’d here) that is his view of productivity, and how it takes a dive. I wanted to echo his graph, and add a little data of my own.
Matt’s Graph:
I think this is an good baseline, but there is some more information I want to add to that.
When I think about productivity of code, I think it can be broken down into a couple of sections. I think one number can abstract it, but I think some background before that number is useful.
- Ideas Are a new design or a good way if implementing something. This is the stuff that happens at the Whiteboard or discussion phase.
- Plans are the I will build, X, they Y, then test X & Y, and after that run Z. They are the skills of breaking a code into a flow.
- Functions are just that. Chunks of code that are a function, be it good, or bad.
- Lines of Code (LOC) are also just that. Lines of code, again, good bad or total failsauce.
- Lines of Usable Code (LOCU) are lines of code that do what you want. I.E, mostly bug-free code that doesn’t need to be rewritten, and doesn’t contribute directly to technical debt. We can also call this Technical Capital.
Adding all that together, I come up with mine own graph of how I think production goes for a week:
Far’s Graph
LOCU (Lines of Code, Usable) is very low. Deal with it. Most developers think they can write 1K to 3K lines of code in a day. That is possible, but only on the best of best days, and that us usually followed by a week of tweaks and updates. Few people reliably get about 10 LOC per hacker-day. Period. If this number seems low, crunch some stats on any project you can get source code for, and you will see it’s true.
Hours 40 to 60 can and do generate useful code, in Week 1. The problem with that is, each week onward, your baseline hacker productivity drops. I’ll cover this more in a follow-up post.
By 70 hours, you are just hurting yourself. If you are still writing code 70 hours into the week, you are simply laying code-landmines to walk into later. Or worse, design landmines to walk into later. By the 70th hour coding you are doing little to no good, and just doubling down on damage. Walk away, or fall asleep in place. Just stop coding.
I nearly added a straight GUD FEEELIEZ lines for felt productivity. Part of the problem is that most programmers type quickly, and feel productive even when they are spitting out garbage code that will just need to be deleted the next day. In a lot of ways, developers (myself included) have little or no internal feedback system to tell them when they are writing crap code, or when they are typing nonsense. Some of the lest productive programmers I know can scramble 60 wpm for hours and hours on end, feel super-productive. … And still have zero function code. Working functionality ships code, not GUD FEELIEZ
Based on 10 years or so of development (at home, and at work) as well as a lot of experience leading teams, I think Matt Rogish has a good (though literally, one dimensional) graph of how productivity works.
Following this, I’m going to get a bit into week-over-week productivity as well.