How Many Hours Can a Programmer Program?

by Krishna on January 5, 2012

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.


Paul W. Homer January 6, 2012 at 7:28 pm

Yep 🙂

A long long time ago I did what was essentially 14 hours per day for six weeks, because someone else made a very bad promise. I managed to get it done, and it even worked, but it wasn't even close to my best work. It was garbled and clunky and just served to diminish the short-term problem (the delivery date).

When I talk with people about building stuff, I generally talk about 'working smarter, not harder'. A programmer thinks for a living and they do an incredibly poor job of it if they are stressed, or too tired, or frustrated. Oddly, sometimes they also do a poor job if they are bored or detached. What works best I've found, is to get into a groove. Generally that means you're happyish and have slept, but also that you have some type of 'life' outside of work which is rewarding. A little bit of 'deadline' stress helps keep away the procrastination or endless refactoring. If you find the groove, you can be there for years, building and delivering on time. If not, you tend to burn out at some point (you can in fact burn out on boredom, weird but possible) and really the only thing that fixes burnout is to move on to another environment.

Funny enough, this type of talk about workaholic hours is usually centered around getting a huge amount of code done quickly, but most often comes out of environments where the prevailing 'tude towards coding is too splat it out as quickly and brutally as possible. It's the hack and hope mentality. But that doesn't actually work in the long run. Crappy, thoughtless code is just crappy thoughtless code. If you want to build quickly and you want to be smart about it, you have to 'reuse' everything, or at least as much as humanly possible. Code is slow and painful to build, nothing can stop that, so if it is only used once you're basically wasting the effort put into it. If you can leverage the same pieces, over and over again, at least by the third use you're way ahead. And that is much smarter than flailing at a keyboard, half asleep, hoping that all those little corner-cases that you're too tired to think about won't come back and haunt you (cause they always come back and hurt you).

Sometimes I think software is the silliest industry 🙂 We've been drifting farther and farther away from what we know works because there have been more and more people entering into the industry who just don't get it. The essence is simple (and well understood for decades), we have to hyper-focus on what we're doing so that we can think through all of the possibilities so that we can write code that doesn't suck. No focus, then no thinking, then crappy code. Simple.


Krishna January 7, 2012 at 12:23 am

Thanks for your comment, Paul. Your point about getting into a groove and having a soft deadline to stay motivated is a good one. The pleasure of software development comes from both the process of building the software and the completion of milestones that result in the product in use by other people.

Technikhil January 8, 2012 at 12:53 pm

To add a bit to what Paul is talking about - the groove, I would like to point out this is not a something that is very easy for programmers to do. In my experience we have a wide variety of distractions that make getting into what I call - "the zone" a difficult task. Programming software is a mentally intensive activity that requires programmers to juggle several layers of abstractions in their head - a distraction in the middle of this can lead to a lot of lost time and frustration. I wrote a post about this a few months back -

Tiro Associates January 9, 2012 at 9:46 am

Great post, I recently read a similar article that discussed the concept of companies that offer more flexible working times with staff that work slightly later but take regular breaks. Research shows that this is a much more productive and efficient way to manage company time.

setty associates February 21, 2012 at 2:05 pm

its hard to judge since programming varies in skill level...i know a programmer that would in a few hours do the work of 2-3 decent developers. So more hrs doesnt mean a better product

Comments on this entry are closed.

{ 1 trackback }

Previous post:

Next post: