I have never known long hours to yield any positive results.
Back in the dot-com days, I was routinely putting in 16-hour days. I found that I spent the first 8 hours fixing what I had fouled up the night before, and the next eight fouling up the code for the next day.
There are clearly diminishing returns after many days in a row of long days. So if the schedule allows, I'm all for getting some sleep.
There are times when you just can't. If it really has to be done tomorrow, you have to work until its done. For me, this is more often writing proposals than writing code. I can't count the number of proposals that were worked on at least 20 hours the last day or two.
When I'm writing code, I can work something like 50 hours a week for several months, maybe as many as six. I can work 60 hours a week for a month or so. I've worked 70 hour weeks for long stretches, but I agree that its usually counter-productive.
I guess that working 50 hour weeks gets maybe 47 hours of real work done. Going to 60 hour weeks cuts it a lot, maybe 48 hours of real work. Which is a terrible scaling factor, you work an extra 20 hours and get maybe 8 hours of more work out.
I had years in the consulting business where I worked 2000 hours of overtime. So rather than the usual 2080 hours in a year (or 2000 hours if you get two weeks off) I worked more than 4000. Sometimes I got rewarded for all the overtime with a promotion, sometimes not.
Bear Bibeault wrote:I found that I spent the first 8 hours fixing what I had fouled up the night before, and the next eight fouling up the code for the next day.
That is so "cowboy". On a well-integrated team, you get someone else to spend the eight hours on what you broke the previous day, so you have time to break even more stuff.
Seriously, though, I always feel that for most things, if you're working that hard, you're doing something wrong. When I'm working long hours, it's usually because I'm not doing well, and I'm not sure what I'm doing. The accomplishments I've been proudest of in my life were great ideas that turned out to be almost trivial to implement.
"All nighters" is one of two all-time delusions of extreme productivity. The other is "multi-tasking". The saving grace is those of us who are self-aware do realize the foul ups we make when we try to do too much all at once. Then there are those team members who are clueless about how their negative work is bogging down everyone else's progress. So, do everyone a big favor and get enough sleep and concentrate on one major task at a time.
Pat Farrell wrote:There are clearly diminishing returns after many days in a row of long days. So if the schedule allows, I'm all for getting some sleep.
This is the crucial point IMO. Working 16 hours or so is productive for a day or two when you're in a crunch, but the returns diminish rapidly beyond that. And over time, there's demotivation if it happens too often.
Seetharaman Venkatasamy wrote:most of the developer stay late night office due to their own or their team mate made foul in code.[ or they might not be understand the requirement properly]
Your experiences might of course be different than mine, but I would say the majority of such cases is caused either by poor planning or by changing requirements late in the project without adjusting the schedule (which is, of course, also a case of poor planning).
I remember reading of a study (and unfortunately I can't remember the reference, sorry) that said that if you draw a curve of work done against length of working week, for the average developer it peaks at 55 hours. Beyond that they introduce errors faster than they fix them.
Lesson Three is this: 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?
Lesson Four is this: At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.