It depends on what the code is. If I'm working on writing unit tests for relatively simple code taht didn't have any tests when it was origionally written I can do 30 hours a week with out to much trouble. If I'm doing new development for non-trivial features I generally can't get 30 hours in unless I get lucky and get in the flow several days during the week.

My 2 cents, if you are working an 8 hour day / 40 hour week than typically I'd expect realistically a 6 hour productive day from most people. This includes debugging, design work, refactoring, writing tests, design discussions, helping other devs on problems etc. But not daydreaming, playing on the web or getting coffee, that's what you do the other couple of hours a day.

This is exactly how I try to do estimating as well, plan on 6hr days for productivity, and tasks are never less than a 1/2 day no matter what anyone says. Even the ten minute task for updating that 1 line of code turns into a few hours by the time you have tested, deployed, communicated and documented the update. And in the few rare times it turns out to be a less time, the bonus time makes up for the some of the tasks that will inevitably run longer.