Programmer's productive work time

Question

Well, this question might be prone to discussion, but I'd really like to know your take on this, SPECIALLY if you are a Lead Programmer, Product Manager, or just if you have programmers that report to you.

A little more than a year back, I started in this company, I was the only programmer there, and I still was in a Jr. level. So after a few months, the company hired another programmer and a software architect. The other programmer and I would report to the architect, and we were going to work with the AGILE methodology.

Well to the point. When the software architect started explaining our roles in the AGILE methodology, she said that our work-time in a day is expected to be only 6 productive hours, not counting lunch break; and she said it like we should already know it. So that means, if we're 9 hours at work, 1 would be our lunch break, 2 to just relax, and 6 to work. I was astonished by this remark since in my then short work experience I have had never heard anything like that.

I'd love to know what you guys think about this. I personally don't feel very comfortable just "chilling out" 2 hours at the office, I always try to be as productive as I can.

But is a programmer really expected to just work 6 hours a day?

Answer 1

I though agree but think she exaggerates. My best hours at work are 11:00-14:00. Ok, maybe 10:00 to 15:00 but that's the limit. After 15:00-16:00 I have sometimes difficulty checking my mails.

At home with my private project it's rather different. Begininng from 16:00-17:00 until maybe 21:00 is the best time. I guess the difference is that I have good slept at weekend as opposed to working days.

Answer 2

Due to unpreventable circumstances (mostly Hulu.com), programmers already do spend only 6 productive hours working, or less.

I've also never heard about anything strict like that - maybe she meant at least 6 hours?

Answer 3

I have heard similar things. Usually this does not refer to chilling out but other things like administration tasks, emails, supporting other apps, answering queries... which would not directly contribute to the primary application. They are therefore expecting 6 productive hours a day on that application. Sometimes its easy to get distracted and difficult to get momentum on the project again.

Answer 4

That 2 hours is to account for things like, going to the bathroom, getting drinks, helping others out and the time it takes to resume what you were working on before the aforementioned interruption. They do expect you to work for the time you've been hired, its just that they realize that you will have interruptions during that time and account for it.

Answer 5

It's a good idea to take breaks during the day, here we have 20 minute coffee breaks during the morning and afternoon which lowers our productivity some but lets us feel less overworked.

Some days it also just takes a while to get into the zone, and being productive. Counting on every programmer having at least 8 hours of productive time each day is not a reasonable estimate from a planners point of view so I agree with her sentiment. Better to count it too low and be surprised, then adjust it later than counting on all time being productive and being disappointed when your estimates are way off.

Answer 6

Not sure if she was making reference to productive time vs. non-productive time.

There are plenty of books out there that discuss this sort of this, "Peopleware: Productive Projects and Teams" (Tom DeMarco)" is one of my favourite. It comments on productive and non-productive time, the impact of interruptions (e.g. telephone) on productivity etc. Also "Joel On Software" (do I get extra Reputation for the mention 8-)) talks about this sort of thing in "Human Task Switches Considered Harmful"

Answer 7

Those 6 productive hrs/day are the result of long-time experience. While you read this at work, a few seconds of your work hours go into those 2 non-productive hours. A project manager that assumes 8 productive hours per day in his calculations is one that will invariably miss the schedule.

Answer 8

I think by saying productive hours, she meant the actually code writing. In general whenever someone deals with development some of his time dedicated to self education process, searching for relevant documentation and etc. Moreover as was said in posts above make a breaks very important either. As well then she was saying this, she was speaking in average meanings.

Answer 9

I'm assuming it has been phrased poorly in the question, weather it was the original wording or not.

If you consider it from the point of view of estimating the time taken for a given work package, you often include a 'fudge factor' (depending on you estimation methods).

If I estimate that a 100% productive programmer will take 6 hours to do something, I'll scale that to a 'real' programmer. My rule of thumb is programmers are 80% productive, the rest of their time is spent checking emails, making coffee, and general goofing off.

Eventually the project manager/software architect/grand pooh bah of work allocation should feed back the actual performance of their team to minimize the need for a fudge factor at all.

Answer 10

Yes, 6 hours of code time, but the other 2 hours are not for relaxing. That's where emails/meetings/dealing with clients all come in.

Answer 11

6 hours per day is lots of productive work! I hardly ever work that much.

Perhaps, by relaxing for 2 hrs and working for 6 hrs, people get more done than by sitting by the keyboard for 8 hrs.

Answer 12

6 hours of productive work can mean a lot of things. But for a job that requires a lot of activities (such as a programmer) I assume that productive work means:

• Thinking about design or looking for answers on the Internet
• Trying to understand the code and discussing about design with your peer
• Construction (coding, refactoring)
• Testing
• Fixing bugs (by debugging, writing new unit tests, fixing code)

If you call any of these activities as non-productive then you're most likely kidding yourself. Actual time used for coding (construction) each day can be somewhere around 2 hours.

Answer 13

She was actually quite optimistic. In IT, a common project manager's guideline for productivity is 60% of the time available. The rest of this time is not "chilling", it can be anything not directly related to that specific project, including phone calls, coffe breaks, emails, chats with co-workers, administrative tasks, personal business, helping a coworker with their project, etc.

It does not matter whether you think you are better and have one more productive hour per day than she would say. The 60% guideline is a statistical average based on benchmark data from thousands of projects. You should consider it as a fact, not an opinion.

Of course there are differences in guidelines, types of projects, types of work, and the characteristics of the individual. This is why we have averages.

Answer 14

I am often the only developer on a project (contractors may be hired in if it's a large project) and I often find that I get burnout if I try to work the full day. When you have nobody to report to and your primary source of assistance is the web and books, there's a lot going on in the old noggin all day. Of an 8 hour day I probably only 'work' (writing code, documentation, research etc) for like 5. I have a half-hour lunch break, and then the rest of the time I chill out.

If you're trying to work out a problem then it really helps to just take a breather for a while and organise your thoughts. Trying to work for too long on something you're both building and maintaining can give you really bad tunnel vision - you end up becoming fixated on one problem area and letting everything else fall by the wayside.

Productivity is a hard thing to maintain, and the best way I've found is to give myself time to relax. I get more done if I work overall for less time, but break the 'chunks' of work up doing other stuff, than I would if I just tried to work flat-out all day.

Answer 15

1. You can't be 100% productive during 8 hours every day. I don't believe it. You do your job with your brain and that is why you HAVE to break sometimes. Yes, you can believe, that it's true, but in fact you get tired and work much slower and produce more and more mistakes, bugs etc...

2. Don't forget about your health. It's not a good idea to sit looking at monitor without any movement. You may damage your eyes and your backbone (maybe smth. else).

3. When you have to plan your estimates - always remember about risk management. Never believe, that all of your 8 hours will be 100% effective, because you are a human and its life with all it's small suprises. Some seconds to yawn, some seconds to think, a minute to reboot after updates, some second to say smth. like "Hi, how are you!" etc... an you have your 2 hours spent without coding in summary.

Answer 16

I think the manager have to find out when and how the individual programmger work best then plan the project base on that data. The one mode fit all approach may not be the best

Answer 17

I say this with 25 years as a programmer and lead/manager: Her statement may or may not have merit, but it isn't relevant to you in your role as a programmer. You're paid to produce working code. Focus on your role, forget the management philosophy, and you will not only be much more productive, but much, much happier.

Answer 18

It's important as a programmer to understand why she is saying that 6 hours per day is what you can realistically get done. When a project is being specified, and the deliverables worked out in terms of what tasks need doing etc, at some point you have to do some effort estimation and give your manager some ETA's. A perfectly respectable method of working out delivery dates is to guesstimate how many hours each task takes, and then work out how many 'development' hours you can do per week, add it all up and then estimate when the delivery date is.

If you use 8 hours per day as what you think you can do, I can guarantee you'll overshoot the delivery date. If the project takes months to complete, then you also have to factor in sick days and holiday, company meetings and all the other non-project stuff that might happen during the course of the project. Your 'development' time can quickly go down to 4.5 hours per day on that basis. In fact when we plan for projects that take more than a few weeks, we use 4.5 hours per day to calculate the time available for development. And to be clear, there is very little 'chilling out' happening here...

Answer 19

I can write code for a block of 4-6 hours before productivity drops due to lack of food. In an office, if I have headphones, I can work 30minutes to 4 hours before an interruption or something forces me to switch tasks, e.g. "Drop everything and do this report!" The context switching is where I loose the 2 hours of productivity a day as I compile, check in code, fire up the other IDE, get latest version, etc.

I only wish those 2 hours of context switching were rest and relaxation!

Also in my experience, any substantial interaction with the humans means 2-4 hours of productive coding, not 6. This obviously is going to vary from office to office.

Estimation in software development does require some brutal honesty about what percent of our time is really spent writing code.

Answer 20

Actually counting on 6 hours of productivity a day is a very aggressive estimate for schedule making. For a smaller company this is probably accurate, for bigger shops with more overhead for meetings, emails, phone calls, etc. I'd recommend chopping 6 hours down to 4 hours.

Answer 21

We use a 60% estimate, but I wouldn't call it 60% productive and 40% non-productive. That 40% isn't there for breaks, but instead is there for all the tasks a person does in a day that do not contribute towards the assigned development task. That could be breakfixing, helping someone else with their project, ad-hoc research, creating reports, consulting with customers/sales/managers, strategy sessions, trainings, travel, etc.

In a large company, you may have a ton of overhead in meetings and conference calls. In a very small company, everybody does everything, so you may have quite a bit of overhead in non-development tasks (updating the website, customer support, mopping the floor).

So it's not that you're building in 2-hour breaks. It's that in a given day, you are probably not able to devote all 9 hours to your development task.