Are there any serious scientific (psychological) studies about the ideal/maximum length of working time for a programmer?

Question

Just curious. I know, in general, this is very subjective and can vary from person to person, but anyway - did anyone do some scientific research in this field?

Answer 1

I would say that flexible working time would be ideal for all programmers and that's probably what most of us are doing.

Answer 2

Some background on subject: Working time

Answer 3

One of the principles of Extreme Programming is "40-hour work week". You might find some studies on how that compares to standard or "Death March" working practices.

You might also be interested in this: http://www.amazon.com/Measuring-Managing-Performance-Organizations-Robert/dp/0932633366/ref=sr_1_1?ie=UTF8&s=books&qid=1256124015&sr=8-1 It's a bit theoretical but has a lot of relevent material.

Answer 4

Not just programmers, but you (and everyone) interested in how we structure our working lives should read the classic E.P.Thompson works on the subject of time and work. The collection of essays in Customs in Common includes a fascinating essay on time and work discipline development in the 17th and 18th centuries.

IANAH (I am not an historian :-) ) but the theme developed here (and by others) is that regular working hours are a development of the industrial revolution and the disciplines required by the capitalist factory owners. Previous to that indications are that we used to work with intense bursts of activity interspersed with periods of leisure and putting things off until later. For example before large factories many occupations were done at home and for example, with weavers, it was common for them to observe Saint Monday before working their buts off at the end of the week to meet the deadlines for getting the piecework back to their bosses. It's also true of other older occupations such as farming and there's quite a body of evidence that your mediaeval peasant would work in a similar manner.

This of course rings very true to how most of humanity seem to work if factory-type clock discipline is not imposed. It's probably the natural way of doing things and seems to hold true for a great many programmers!

Answer 5

My empirical experience tells me 4-5 hours of full commitment per day. No more.

I also have some personal projects in the evenings so I code more. But that's because there is a significant context changes and a pause during the trip home.

I have also read some studies that it is more productive to work like about 10 hours per day then take a day off. But I have my doubts how this will reflect on the health.

By common agreement among programming folks however, the 8 hours per day with full commitment and full energy is usually not achievable. Unless you're working on your start-up but that's a different story and a different motivator that a normal employment can never provide.

Answer 6

I believe Tom DeMarco wrote that one shouldn't work more that 8 hours (actually, I even think he wrote something less, like 7h30 or 7h). I can't remember if it was in Peopleware, Slack, The Deadline or somewhere else.

(EDIT2: Found some references about the above statement that I'm pasting below)

In the Shorter hours in software article (Feb 22, 2005), we can read:

Overtime overrated

Research indicates that long hours don't translate into heaps of extra work. Consultant DeMarco has studied productivity data and concluded that workers putting in 44 hours per week generate the same amount of work as those who put in 36 or 37 hours.

"There's nothing to be gained from the extra hours," he said. DeMarco argues that there are limits to how much people can churn out without adequate breaks, and companies with cultures of long days tend not to run meetings in a disciplined fashion.

In "Crunch Mode" (24 Feb, 2005), Jim Shore wrote:

Tom DeMarco reports in his book Slack that extended overtime has no effect on productivity:

The best predictor of how much a knowledge worker will accomplish is not the hours he or she spends, but the days. The twelve-hour days don't accomplish any more than the eight-hour days. Overtime is a wash. [DeMarco, p64]

And finally some quotes from Excerpts from The Deadline – Tom DeMarco (14/04/2006):

The Effects of Pressure (p.199)

• People under pressure don't think any faster.
• Extended overtime is a productivity reduction tactic.
• Short bursts of pressure and even overtime may be a useful tactic as they focus people and increase the sense that the work is important, but extended pressure is always a mistake.
• Perhaps managers make so much use of pressure because they don't know what else to do, or are daunted by how difficult the alternatives are.
• Terrible suspicion: the real reason for use of pressure and overtime may be to make everyone look better when the project fails.

---

(EDIT1: While browsing for something else, I found this great blog post mentioning studies, Why Crunch Mode Doesn't Work - lessons from EA Games, in which Darrell Norton writes:)

igda, the international game developers association, has an article by Evan Robinson called Why Crunch Mode Doesn't Work: 6 Lessons. It's an excellent rebuttal to any management's attempts at forced overtime (I've heard it called "mandatory voluntary overtime" at one place). Citing numerous studies on workplace productivity, Evan comes up with six lessons.

1. Productivity varies over the course of the workday, with the greatest productivity occurring in the first four to six hours. After enough hours, productivity approaches zero; eventually it becomes negative.
2. Productivity is hard to quantify for knowledge workers.
3. Five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century. What makes us think that our industry is somehow exempt from this rule?
4. At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.
5. Continuous work reduces cognitive function 25% for every 24 hours. Multiple consecutive overnighters have a severe cumulative effect.
6. Error rates climb with hours worked and especially with loss of sleep. Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?

For managers that need a good rule of thumb:

"... at approximately eight 60-hour weeks, the total work done is the same as what would have been done in eight 40-hour weeks."

And my favorite:

"In the short term, working over 21 hours continuously is equivalent to being legally drunk."

[via the ever-vigilant Lasse]

The original link to Evan Robinson article doesn't seem to be working (at the time of writing this) but the article can easily be found on the web, for example here. As Evan wrote, most of the cited references are available on the web. You'll like this.

Answer 7

Very interesting question. I'm full time Java developer at work 9 hours per day except Saturday and Sunday. But I'm student (I'm finishing bachelor degree this year) and as you can guess I'm trying to study as much as possible, so often after work coming home I'm working on my own little projects and then reading some good articles or watching lectures. I understand it's not so good for health and maybe it's horrible too but what I can say is that I like it :).

Answer 8

There are some good ideas about how to manage your working pace/time (backed up with some psychological background) in The Pomodoro Technique book. (The pomodoro technique in general is getting quite much attention these days. I recommend reading the book - there are some really useful ideas in there even if you are not going to use the technique itself.)

For me the ideal (which means productive) day usualy consist of aprox. 12 pomodoros (which means 5 hours of pure productive work).

I also found this presentation which deals with the PT and also makes some more concrete statements about how it could be used in the XP environment:

A typical day in a XP team using the PT stand-up meeting (max. 1 Pomodoro) 4 Pomodori for work (usually in pairing) a longer pause (usually 15’, max. 1 Pomodoro) 2 Pomodori for work (usually in soloing) lunch 1 Pomodoro for a team continouspective 2 Pomodori for work (usually with different pairs) 1 Pomodoro for PT recording Total: 10 pomodori per day

There is also a study by the same authors with the same title, but I haven't read it, yet.

---

Another interesting site to look for many ideas related to this topic is this wiki. Eg. pages about sustainable pace or forty hour work-week could serve as good entry points. Just dive in.