0

Something came up in another post that I think can be settled by reference to actual published studies:

How many hours should a TYPICAL software developer work over the LONG TERM in order to maximize his/her TOTAL productivity?

Note that I'm talking about a software developer doing software development work. I seem to remember a Steve McConnell book where he actually gives a figure from published studies, but I'll have to go look it up. And I'm sure there are others. I'm hoping by "crowdsourcing" this question I get a more complete answer.

Note that I'm not talking about the number of hours over which you maximize your average productivity - that isn't my question. I'm talking about the point at which, if you do more hours of work long-term, you will actually reduce your total productive output due to making mistakes. Note that this is not an opinion-based question either - I'm hoping I can find stuff from actual scientific studies.

3
  • 1
    One should keep in mind that the result of any study in the literature will always apply to a population of workers, and not specific individuals. Apart from that there are complicated considerations here such as how much of the hours are "billable", how much are consumed with administrativa, and how much are down-time. – teego1967 Aug 5 '15 at 12:02
  • 1
    This questions is probably better suited for the Personaly Productivity SE – David K Aug 5 '15 at 12:42
  • 1
    I think you're close to oversimplifying the problem. One's productivity is a function of great variety of parameters, hours spent over a keyboard being just one of them. – rishat Aug 5 '15 at 12:43
2

Breaks

  • Before thinking about the length of your workday, you must prioritize breaks. In order for the brain to be in good working condition, you should take two 15 minute breaks in the morning and evening and a half hour to an hour break for lunch. This should result in your brain not only recharging, but you socializing with your coworkers, which is a key component of a successful workplace.

Hours

  • When I work, I try to limit myself not by time but by project productivity. At the beginning of each day (or sometimes the end of the previous day), I write out what I need to accomplish the next day. This comes from my weekly project plan and sometimes my monthly project plan. You should definitely limit yourself to 10 hours a day (including breaks) if you cannot finish your completed tasks before then. If you end up finishing them before 8 hours, perhaps find something small to do.
  • The danger of working "hourly" is that your brain will constantly be thinking about time and the clock. It's actually healthier if you have a variety of hours every day. If you set a limit for 8-10 hours, your brain will work faster and be more productive. If you tell yourself that you need to work 10 hours a day every day, then you really won't be getting anything productive done in the long term. If you limit yourself by projects and workload, then you'll find that your productivity levels will rise.

Company Policy

  • Make sure that you understand the company policy on fluctuating hours.
1
  • "The danger of working "hourly" is that your brain will constantly be thinking about time and the clock": This sounds good in theory, but in practice people have places to be at specific times. How would it affect your home life if you always came home at a different time. – Brandin Aug 5 '15 at 18:04
1

I don't have an exact hour nor do I know of any research out there that has looked into this, but I do have some suggestions on what it would take.

Measure Total Productivity Output This is a tough one especially when comparing one programmer to another and changes from project to project. Some environments produce more stress in one day than others do in an entire year, so the hours worked aren't equal in terms of sustainability. A Single Subject Research design could be done. You would need to establish some sort of baseline and then control for the additional hours.

Considering the Affects of Bugs Although a programmer is continuing to write more code, increasing bugs and therefore spending a larger percentage of the time reworking the same requirement, is extremely counter-productive. It doesn't have to be the result of an accumulation of over-worked hours, but could happen in one evening of extreme fatigue. Causing catastrophic loses for your top client would be much worse then a few bugs here and there. Both could take the same amount of work to create and repair, but the damage is very different.

Acceptance of Risk Every project has a level of risk. If it means the difference between being first to market or reaching a milestone for a big client, companies will choose to just go for it. The question is about the long-term affects, but unfortunately, few managers can think past the current emergency. All the "emergencies" add up and before you know it, the staff has left or worse burned out. The myopic manager is the last to know.

All of this could be done to perform some sort of analysis on individual developers. For a less formal approach, I woudl say if you start to find it hard to get out of bed in the morning and you dread going to the office, you may be working too many hours.

Not the answer you're looking for? Browse other questions tagged .