HN Explorer

Ask HN: How many hours can you productively program a day?

49 points by porker ↗ HN
I'm just negotiating a freelance job with a company, who want 'day' rate quoted. Being me, I want to define day: usually it'd be 8 hours.

However, I know I cannot program productively for a solid 8 hours.

How many hours do you do, and how do you handle it on such contracts?

57 comments

[ 3.2 ms ] story [ 99.9 ms ] thread
mbenjaminsmith
I can do 8 or 9. I can do more than that but not for sustained periods.

If I'm programming 10++ I'll usually burn out after a month or so. Burn out usually means that I don't have the focus or will to get in a solid 8, more like 4 - 6, for a period while I reset (whatever it is that gets reset).

Daishiman
It shouldn't be more than 5 or 6; you still need time to arrange the rest of your business. Plus, you're not wasting it around with meetings and other nonproductive, non-billable stuff.
peteretep
I would (and do) avoid defining a day with the client - much better to leave it slightly nebulous. Internally, I use 6 hours of actual typing and thinking.
mattgreenrocks
Yeah this guy knows what's up.

Bill based on the value you bring, not the time you spend heads-down.

porker
Unfortunately clients don't seem to think that way. This particular client has told me "I know everything", that they want my skills and my brain to provide input as they get their startup going - but they still want to bill based on days, and set a day rate.

I've read enough by @bdunn, @patio11, @tpacek et al to know that billing based on the value I bring is the best way to bill. Getting to a position where clients will consider it is... not happening though.

How do I break this blocker?

peteretep
Billing on a day rate is a good thing, just don't define day too carefully.

The other alternative is billing on a per-project basis; that gives you precisely no protection against clients wasting your time, or changing your mind, or any number of other things.

mattgreenrocks
Yeah I wouldn't be too bogged down in day vs. week billing. Obviously, a larger scope is preferable, but it's much better than simply billing by the hour.
joss82
Probably not more than 4, but it doesn't matter. Most of your working day at any non-trivial project would be devoted to understanding (reading, communicating) and documenting (writing, communicating) what you're programming about.

After 6-7 hours of programming, my code quality tends to dip dramatically, without me realizing.

With terrible impacts on the next day's productivity, of course.

seren
I think this is the right approach, you can't compare programming to working on assembly line, i.e. the more time you spent typing in your editor is directly translated in more goods or value to the customer. Even if you should fill something like hours spent programming, I don't think it should be interpreted that literally. Your customer is buying your overall expertise, not only the ability to translate requirements into machine code.
raverbashing
Yes, if you can shuffle the non-programming tasks to fill up your day that's helpful, I usually put the emails/meetings/etc in my least productive part of the day

Harder to do if your job involves only programming

kyriakos
I used to do 8+ but recently I find myself doing 4-5 at most. Maybe I'm burnt out after 10 years at the same job (I quit a few months ago but still I am nowhere as productive as I used to be). I also find it very hard to reach the feeling of flow without being distracted.
magnet1c
I estimate 5 hours is my max without quality loss.
vemuruadi
5-6 Hrs is good for programming for a day, productivity goes down if we stretch.
perlgeek
About a half hour to two hours really productively, and maybe 6 hours in a somewhat productive way.

It varies a lot with the amount of sleep I got the night before, which again varies a lot, having two small children :-)

walshemj
a really good day with no outside interruption interruptions 5 hours would be my guess.
Raphmedia
That would be 6 hours. Over here, on a 7.5 hours shift, we are expected to spend 6 hours actually programming. The other hour is there so you can take breaks, have meeting, etc.
yoodenvranx
What do you mean when you say "programming"? Sitting in front of the keyboard and typing? When I do "programming" I spend at least a third of the time with a pen and pencil and thinking about the structure or algorithms.

Without sitting down and thinking I just don't have enough good ideas in my head which I could type in for 6 hours straight.

Raphmedia
I mean everything that is typing on the keyboard or at maximum a step away from it. Thinking about the code would be included in that.

That being said, we do have a around 6h a week of Agile meetings. Usually split into 3 x 2h meetings. Depends on how each team wants to proceed.

Of course, if I have to attend meetings, talk to clients or work on the structure of a project, I'm not expected to do that in overtime. I cut in the 6 hours. But on a 7.5h shift, we are expected to spend 6 hours on average typing on the computer.

It's not like anybody is looking over my shoulder however. If you work faster by making pseudocode on paper before you start working, you would be allowed to.

groktor
In project planning I would plan for 5 hours per day per developer, even if they were going to be onsite for 8 hours per day. My experience with freelancing/contracting though is that you're generally expected to be onsite or to be available 7.5 or 8 hours per day, even if you're only productive for 4 or 5 of those hours...
__xtrimsky
Mine would be 4 to 5. But on average I can get done more than most people in that amount of time.

But for freelancing I do quote 7-8 hours. I just program slower during that time, do easy tasks if any (css/html)

notduncansmith
> I can get done more than most people in that amount of time.

Not challenging you, just curious - how do you measure this?

__xtrimsky
I haven't timed anything, but just by working with other people in different environment, I seem to always get things done faster.

Or comments like "are you chatting or are you working ? Why are you typing so fast".

My issue is that I sometimes jump into something too fast. I don't over think projects, and sometimes it leads to me making mistakes. But I am working on it.

amouat
Most contracts I've been involved with define a day as 7 or 8 hours.

This is almost never going to be solid programming time though, as you will need to communicate with the client, handle documentation and other tasks which legitimately take up part of the 8 hours. Also, you should take at least 1 or 2 breaks during the day which shouldn't be included in the 8 hours.

By the end of the day, you're not going to be programming as effectively as you were at the start. This is just the nature of working 8 hour days; the client won't expect you to be a machine. If you're really concerned about this, try to do all the difficult thinking and planning at the start of the day, leaving more straight-forward tasks for when you're tiring.

In short, say you'll work 8 hours and just do your best.

LeicaLatte
My Wakatime reports about 4 hours of Xcode per day.
Cthulhu_
4 on a good day; very rarely 6, but that's often more repetitive refactorings or a very quiet, distraction-free day. Usually though it's either I get disturbed in one way or another and have to do the whole restarting / getting back in the zone rituals, or I'm mentally beat after a good bout of programming.
lostcolony
It depends a lot on what I'm doing.

If I'm actively engaged with something, like a new algorithm, or the guts of a system, something really compelling and which is 'solvable', i.e., I've got everything nailed down enough that I can fit it into my head and start figuring out what bits are missing, I can achieve flow pretty easily and get maybe a solid 4 hours in that state, with another 4 hours taken up for less productive work getting into and out of that state, and for periodic breaks when I need them.

If it's defining the problem, exploratory coding to try and figure out how to interact with an external system (and that system is documented and sane), probably 3 in flow, with another 3-4 less productive; I'm nearly as productive as when I've got everything I need in my head, but I get drained faster.

If it's drudge work, or just hitting my head against a wall (anything trial and error-y, like interacting with something undocumented, stupid, inconsistent, painful, etc), perhaps 2 somewhat productive hours, over the course of 6 hours (the other 4 aren't productive -at all-), since every single thing will distract me, and after 6 I'm mentally exhausted.

lostcolony
Also, while I have never freelanced, I would define day rate as simply "not to exceed 8 hours". If they want to make it exactly 8 hours, fine, but that's where ethics comes in. For myself, if I'm mentally spent, and recognize I'll do more harm than good if I keep trying to code, I'm okay with simply keeping an eye on email and responding to them (rather than only responding to high importance ones/phone calls), and if any non-mental tasks are available, doing those (documentation, minor refactorings, additional test coverage, etc).

EDIT: foz's comment x 100. Make it clear they're paying for exclusive rights to your time, not 8 hours of programming.

notduncansmith
It's great to hear that I'm not the only one who runs into the last one sometimes. In fact, this comment pretty much hits the nail on the head for all my productivity phases. Hello, friend.
andrey-p
4-5 hours on a good day. I normally quote a day rate for 6 hours / day, but this can vary depending on where I work.

I tend to be more productive if I work at a client's office rather than my usual coworking space. I assume that's because of feeling pressured to look like a good freelancer, but it makes me enjoy work a lot less.

porker
> I tend to be more productive if I work at a client's office rather than my usual coworking space. I assume that's because of feeling pressured to look like a good freelancer

Same here - on those days I fly, I look like a genius.

Unfortunately, the next day I'm burned out, and the one day they paid me for turns out to have to cover 2 days.

valarauca1
You'll likely only program 5-6 hours per day, unless you're super excited for the project. I'd still quote 8 because while you'd only program for 5-6 hours, you still have to deal with email/phonecalls/text messages as part of your job, which are part of your work for them.
moron4hire
In the scenario you present, I can get 4 hours of programming done in a day. The rest of the time, I'm emailing, thinking, writing, talking on the phone, etc., I'm not just goofing off on the interwebs. Software development isn't just programming, especially as a freelancer.

I don't quote clients based on how long I think it will take, or how long I think I can work. I quote them based on the profit I want to make. And some clients, who have projects I don't want to do, get quoted ridiculous rates. It's been somewhat surprising to see how many have gone even for that.

I charge per-day, not per-hour. I sometimes evaluate quality of life issues around a per-hour basis, but I think the smallest unit of work-time is a day, not an hour, so I charge by the smallest unit. I find this makes me a lot more honest about my time accounting, as there is no temptation to pad time with goofing off.

julie1
It depends of your health and your sleep quality.

In good condition I exactly say like jos82.

When in pain (I have a back neck pain killing me since 2 weeks and it seems related to my working position) It is unsustainbale to focus even on other tasks than programming for more than 5 hours a day and sometimes less (like 3).

When going into burn-in (like mbenjaminsmith, or Daishiman) I can focus up to 8-10h+ a day, the problem is the burn-out: Months with reduced concentration and almost a negative productivity in quality and quantity some days.

When in good physical and psychological condition, I focus the same amount of time, but quality of code is way better.

At home, the lack of noise and unwanted interruption increases the capacity of concentration and I can code 6 hours with better quality. The lack of social interaction however on a long run however erodes my pleasure of working, so I don't do it too often. (but it should also happen in good working environment or with good mental Daishiman or walshemj).

Stresses debilitates me, so I code way slower and with poor quality during a crunch unless I kick a burn in.

That is the reason I prefer a balanced solution.

It is kind of funny we have the same feedbacks.

I have a theory that the difference between 4-5 and 5-6 is the difference between a crowdy working environment and a quiet one.

Could some of you tell whether you work in a crowded or a calm place too? It would be fun if I was right.

bguthrie
A day rate means a day's worth of your time, not necessarily of your code, and a standard workday normalizes to 8 hours. Don't sweat time on keys and be as productive as you'd normally be. If you'd normally take periodic breaks, take periodic breaks; the same goes for other work habits. If you can't code continuously for 8 hours (and most people can't), find other ways to contribute your skills. I believe this is fairly standard consulting practice.
ritchiea
Another interesting question is, given that responses seem to be in the 2-7 hour range, for programmers that report 10+ hour days at your startup, where is that time going? Are you constantly working past the point of exhaustion? I can productively program 4-6 hours a day. In a pinch with rough deadlines I've pulled all nighters (these were for personal projects with hard deadlines of a scheduled event). But if I am trying to put in 8+ hours of programming daily I would be a wreck.

What are 50 hour a week and up programming jobs like? Do you just tough it out and code endlessly?

bkmartin
I have always wondered this myself. I find it more difficult to stay focused on a project that is not well defined, but for ones that are well defined and give a clear picture of the expected end result I can get into the flow for hours as I run off the checklist of things that are expected.

I think that ambiguity kills programming production, and in this industry there are copious amounts of horror stories about poorly defined projects. And I don't think that documentation is some sort of mindless work break either, as someone above eluded to. Being able to effectively explain your code from a technical and/or functional standpoint also takes focus and energy.

lostcolony
Very much this. I think 'agile' has been abused a lot by product manager-y types (anyone filling the role) to try and excuse nebulous, ambiguous tasks as being okay to work on ("do your best, that's what we're paying you for; figure out what it should do"). They're okay to have ("we're not sure how that's going to work yet"), but they're not okay to start working on until you nail it down, and nailing it down can be as hard or harder than the actual implementation.

Also, as clarification, documentation can indeed be mindless. "This REST API has changed and needs up to date documentation; let me go look at the code and find the new endpoints and write them down and what arguments they take" is a completely menial task.