This is a reblog of Krishna Kumar's post (How Many Hours Can a Programmer Program?) on ThoughtClusters.com. Considering how many people, and not just developers and people in startups, think that if you slave away for hours on end, and work twice as much as the next guy, that you will be guaranteed more success, this is a very appropriate and practical look at the question of how much work you can actually work.
The IT/software/tech/dev community -- and for that matter most people that are involved in some sort of R&D -- has long idolized, or at the very least looked up to those people that "slave away" in their caves and dungeons, assuming that that is where "the magic happens" and where all of the great successes come from. The old saying "Work smarter, not harder" still applies, even when you talk about programming.
Below is Krishna's post.
How Many Hours Can a Programmer Program?
I am a little late to this party where Michael Arrington says that startups mean working hard and sleeping under your desk. But I will add a few words. I read a lot of commentary about how such death marches can be counter-productive and ultimately unsuccessful, and also the real dangers they pose to the well-being (short-term and long-term) of the lives of the programmers. But I didn’t see many people actually do a quantitative analysis. So here it is.
Your average working day is 8 hours and the average week has 40 hours. Now, in the absolute best case (unworldly) scenario, your startup has a programmer who does nothing other than program, 24 x 7 (not even sleep). That translates to 168 hours, which means you have a programmer working 4 times harder than usual.
But of course, programmers are not machines running all the time and even those break down. They are subject to the same biological needs that other human beings have. Like, sleep. The optimal amount of sleep for human beings is between 7 to 8 hours. Now, you can survive a day or two with less sleep, but it will catch up and in the meantime, you are operating at below-peak efficiency and it is a wash. Using an estimate of 7.5 hours, we are down to 115.5 hours.
Then food. And you need to first get the food (order or cook) and eat it, at least three times a day. On average, let us say that takes 30 minutes per meal and 90 minutes overall. Now, if you are ordering pizza delivered all the time, maybe you can bring that down to 15 minutes per meal and cut that down to 45 minutes. So, let us average it to an hour per day. We are down to 108.5 hours. Hygiene? Brush your teeth? Take a shower sometime? Best case, let us say 30 minutes a day => Down to 105 hours. Commute from and to work? The average commute in 2007 was around 45 minutes round-trip. 5.25 hours per week => Down to 100 hours. Maybe you can reduce that by sleeping under the desk!
At 100 hours, that is just working two and a half times more. And we have not even talked about productivity, family needs, illness, having friends, non-work needs and activities, etc. For all intents and purposes, you are looking at somewhere between 10 and 14 hours of work 7 days a week. And even that can only be sustained on a short duration (months).
So, here is the question: Is working about 2.5 times more going to make your startups yield the astronomical (i.e., 10 times or 100 times) returns expected? What is the value of the extra 150% put in by the programmer? Does 40 hours a week mean regular company returns, and 100 hours means Facebook-like valuation? And if that is the case, why not hire extra programmers while you are at it? Seriously, if putting in more hours means a huge guaranteed return, then surely adding more people gives you bang for the buck, right?
If not, why is it not? And why do people like Arrington and Jason Calacanis want people to work themselves to death? One possibility is that they don’t know how to count and seriously think that working a few extra hours suddenly translates into huge profits. I think there is something subtler happening.
The truth is that even with sophisticated metrics collection at work, you cannot properly gauge programmer productivity. There are ways to game the system, and even if people are not trying to game it, you have to spend time looking at the code in detail to see what is being churned out. People like Arrington don’t have the time or the expertise to do that. Instead they measure productivity by the number of hours the programmer is available to them. This means how much time the programmer is at work (they must be coding every second!) or how easily they can reach the programmer when not at work. If a programmer picks up a call from Arrington at 1 am, she is practically working all the time, regardless of the fact that it might only take her 10 minutes to answer the call and fix an issue.
So while Arrington and Calacanis say and even think that they want the programmer to work all the time, what they actually want is the person to be available all the time. More so because they cannot produce or fix anything without their help. This has nothing to do with startup success or failure. You can read similar stories in established companies with stupid bosses, where leaving one minute earlier than the boss has a whole different meaning than leaving one minute after.
Source: How Many Hours Can a Programmer Program? -- thoughtclusters.com
So, maybe this?