What is the maximum number of hours should you do programming on a normal day?

Question

We know there is a maximum number of hours that a programmer can really be 'effective' in a day. Human mind has a limited capacity to work at a stretch, more so when the work is creative in nature. There is certainly variation per programmer but not much. There have been studies which evaluated how and when were most of the bugs were introduced in the product and significant percentage of them were when progarmmers were made to work extra/long hours.

I have even seen experienced programmers making mistakes in code check-in and standard repetitive procedures when they were working overtime. As Peopleware writes "when you make your programmers work overtime, they dont work harder, they just work faster".

So folks, what do you think, in a normal working day assuming he is taking all the coffee breaks in the day regularly, should be the maximum number of hours that a programmer should be working (or made to work)?

Answer 1

I think 8 to 9 hours is about the most you can be productive for. Anything after that and it's diminshing returns and you start to get tired and make mistakes. I'm sure many readers here have written code late into the night only to come in the next day, take one look at it, and realize that it's rubbish!!!

I've worked for companies where the ethos is that the more hours you work the better an employee you are. The managers in these places tend to have a non-technical background and fail to realize that programming is a creative process and as you get tired you tend to be less creative and therefore make more mistakes. I can still remember an annual review where my manager compared me to another employee who worked more hours. When we suggested I be more like this employee I pointed out that I managed to deliver better work by doing less hours!!! When my manager replied "yes, but he works more hours" I knew I wasn't going to win the argument!!!

Answer 2

I suppose it depends on how long your attention span is, given what you're working on. Some days, if I can get really motivated to do something, and can guarantee myself no interuptions, I can go for hours and hours without stopping. On other occasions, when I working on something hideous, I just can't get into "the zone" (because I'm too busy silently cursing the original author) and can't concentrate for any significant length of time.

I find working on bad code mentally taxing, and thus drains me quicker, whereas working on good code is quite rewarding and doesn't drain me at all (in fact, in a wierd way it's actually quite refreshing - it hardly feels like "work").

Answer 3

Programming is similar to running. With practice you increase condition and the problems that took a lot of energy in the past become a routine so you don't burn as much energy as you used to at the beginning.

But otherwise I believe all of us have limits and sometimes taking a break and continuing work next day is more helpful then using "brute force". I usually spend around 8 hours at work and try to spend at least an hour daily to learn new things.

And one very important thing... physical work and relaxation is indispensable to increase creativity. 2 hours of physical training and 8 hours of work are certainly more productive than 10 hours of pure work.

Answer 4

Well, for starters I think it depends when you work, as well as for how long. Finding the balance between hours worked and when you're most effective is the key.

I'm a bit of a late start/late finish person myself. Most of my best work happens in the afternoon and also in the evening and yet I know many excellent developers who are the complete opposite.

So, I'd have to agree with some of the other answers here - early in your career whether you're producing or not, there seems to be some expectation that you work longer hours, probably 10+ hours per day - especially around release dates.

However, looking back I think that more harm was done in those late night sessions (or really early starts) so perhaps that's not the best way to operate.

The focus needs to be on quality output, not bulk hours logged. If you're having a hard time convincing management, you might need to look at how the business reads metrics.

Ultimately, I think we tend to work longer hours when we know we need to do so to get the job done, but as long as there is an even balance - i.e. work hours decrease after a long ramp up then life tends to balance out.

Answer 5

As for many others my attention span is something that varies a lot due to fatigue, interest in the project, the delays, the technology, the nature of the tasks.

Normally a 7 hour day seems to do it, but on some occasions when the tasks seem repetitive, I tend to zone out easily. To fix this I personally need to find distractions to help me break out from this trance to be productive. On other occasions when I’m learning something new and pushing further in new technologies, I easily get into the zone for hours on end. In these times, the best is no distractions and no breaks. Either of these makes me lose my trail of thought.

But in the end the question should not be how many hours a programmer should program to keep his productivity up. It should be more along the lines of what the optimal work day schedule should be. I know for a fact that my most productive hours in a day are not always bound to the 9 to 5 schedule.

Another question that should be asked is, are my programmers using the right tools? Is this taking too long? Could this be done differently?

Answer 6

With some experience, You may have a sense of detecting the following situations:

• "This should be simple, but I just do not get it."
• "I cannot concentrate on... erm... wait... erm..."
• "It's hard to stare on the screen."
• "I could just copy-paste the whole stuff in the new module."

These and similar thoughts are good indicators for a neccessary break or the end of the work-day. It should not matter, if You experience this after a six or after a eleven hour work day.

Answer 7

I feel I should spend more time thinking, and less time hacking something together.

So in terms of a 8 hour day, unless I've got a plan for the entire day, I try to limit it to two four hour stretches, and in each stretch sit back for an hour and think about what I'm trying to do and if there's a better way of doing it.

That and a big lunch in the middle :)

Answer 8

For me.. i'm also a late guy.. the best practice for me is not how long did you code.. but its a matter how long you plan to write the code.. the cause of being exhaust is that you can't get the answer of a possible problem. take a break and plan your answer.. it is much better to think for the solution first.. i think this is best routine for managing your programming practice hours..

Answer 9

If you are working 12 or 14 hours a day when do you go do important stuff like banking and grocery shopping? Usually you end up running errands at lunchtime with everybody else and that 1 hour turns into 2 hours are you still haven't had anything to eat.

The real problem is that if you estimate that something can be done in 3 months and then you end up working 12 hours a day (including weekends ) to deliver it. The reality is that you expended 6 months of effort instead. If hard worked regular hours the estimation error would have been more obvious.

I would rather be ridiculed for my bad estimation than divorced or dead. I really have seen both happen in stressful environments.

There is a Live Journal post called EA: The Human Story on experiences of this at Electronic Arts.

Answer 10

Some factors that would limit the amount of time you should be spending:

• Do you manage other people as well?
• How important is your family?
• How important are your friends?
• How important is your health?

Answer 11

If it's a hobby, do it until you fall from your chair by exhaustion. If it's a work, do it 8 hours maximum. :-)

Answer 12

I think this depends on what you consider "programming"... if you are only including banging out code or if you include thinking about what you're doing.

Normally, for me, when I don't have any other extra meetings to go to, of the 8 hours, I usually spend about 5.5 hours of the day coding, the rest in meetings or thinking about the code I wrote or am going to write.

I've found that when I have to go to work on Saturdays and there are no interruptions, my productivity is about the same, and I find myself needing to interrupt myself, get up, and walk around for about fifteen minutes because my brain isn't used to such prolonged periods of coding at work.

Answer 13

Danc from Lost Garden has recently put up a short presentation relating to productivity. He even provides references at the end, if you're interested in the sources of his data. But the most important points are:

• The 40 hours/week for manual workers "standard" is actually based on research. Longer workweeks provide a measurable decrease in productivity.
• Knowledge workers (such as programmers) have an even lower long-term productivity optimum - 35 hours/week
• 35 to 40 hour weeks can be divided in a variety of ways, such as four 10-hour days and three days off

My favorite part is slide 18, titled "Humans ignore the systematic costs and psychological biases" - such as "Self reported excellence":

These cognitive biases are all exacerbated by lack of sleep. Crunch makes smart people stupid. Especially if you are 23 and have very little work experience.