Take a look at Brooks' The Mythical Man Month for data that demonstrates the opposite, at least in programming; I haven't followed the field closely, but education and industrial organization researchers have done similar work in other professions.
Take a look at Brooks' The Mythical Man Month for data that demonstrates the opposite, at least in programming; I haven't followed the field closely, but education and industrial organization researchers have done similar work in other professions.
I mean officially I was there 37, it was a good week if I was doing real, actual work for 20. Yes, I made up for it by working my tail off when it was needed.
We coders can be absurdly productive for short bursts, or be slow and steady. You can't have massively productive and steady for very long. In your early 20s you have a few years of this, but the more you push it then the more jaded you'll be later.
All said, I expect some loss of productivity is inevitable due to context switching and communication overhead but it isn't necessarily a major loss.
Brooks' book also clearly demonstrates that applying a dumb formula derived from the number of programmers doesn't predict the output, and using such a formula to estimate a project's timeline doesn't positively affect the project's outcome. It's main argument is that programmers added late to a project will actually cause it to take even longer to complete.
Brooks' book is remarkable - a lot of programming lore and culture originates there or is popularized by it. I'd compare it to casablanca or citizen kane rather than dismiss it out of hand.
The easy way to combat this is to have longer timelines for projects, or, if necessary, crunch periods followed by more relaxed recharge periods.