
Ask HN: How many hours can you productively program a day? - porker
I&#x27;m just negotiating a freelance job with a company, who want &#x27;day&#x27; rate quoted. Being me, I want to define day: usually it&#x27;d be 8 hours.<p>However, I know I cannot program productively for a solid 8 hours.<p>How many hours do you do, and how do you handle it on such contracts?
======
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.

------
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.

------
foz
Assume 8 hours * your hourly rate. You won't be programming productively for
all eight hours probably, but that's normal. Be sure to point out that the day
rate assures that you commit to focusing on them for the entire day, being
available, and not working on other client work. This is the expectation of
day rates for most clients: predictable scheduling and reachability.

~~~
lostcolony
This. Resolve any ethical ambiguities by making it clear that they're paying
for the exclusive right to your time, not a guaranteed 8 hours of programming.

------
bradfa
If they want a "day" rate why not just charge them what you want to make per
day? Assume you won't work on anything else that day, how much do you want to
make in a day?

Does it really matter how many hours you'll be productive? Hopefully this
customer is paying for YOU and not your code. If not, how do you make it so
they are paying for YOU and not your code?

I'm not a freelancer, I'm in a salary position. But I get the same amount per
day regardless of if I write code for 8 hours, write emails for 12 hours, or
only spend 4 hours in the office due to a company picnic. If someone asked me
what my "day" rate is I'd say around $500, as that's roughly my employer's
fully loaded cost for me to be employed for a day that I'm not on vacation.

~~~
porker
> Does it really matter how many hours you'll be productive? Hopefully this
> customer is paying for YOU and not your code.

When sat in their office I am sensitive to the perception that I'm not working
hard -- and in normal management style, not worth the money (because I don't
look busy).

I guess I also have a strong protestant morality of not overcharging - and if
they hire me for an 8 hour day, I'd darn well better give them a proper 8
hours' of work.

~~~
bradfa
> if they hire me for an 8 hour day, I'd darn well better give them a proper 8
> hours' of work.

If I was to hire you, I expect I will pay you your rate for the emails you
send to me telling me status of your work, for the time you spend researching
the problem at hand, and for telling me that if I compromise on one part of
the development that I would get $BENEFIT and that I should change my
specification to get $BENEFIT. None of this is writing code but all of it is
very valuable.

I've come to realize that people who write code are not as valued by those who
authorize the writing of checks as people who can communicate and get shit
done. It doesn't matter if you write code well, it matters that you get shit
done and communicate about it to others.

------
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.

------
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.

------
Silhouette
I also vote for maybe 5-6 hours on average.

That's "active" programming time, meaning things like designing with software
tools or pen/paper, literal programming time where I'm bashing on a keyboard
and compiling stuff, and immediate testing activities.

I'm not including things like time for running automated testing suites,
making general notes, or overheads like calls, meetings, and reviewing specs.
I don't find these activities detract from my concentration on detailed
technical tasks in most cases.

I've noticed that if something really grabs my attention -- maybe because it's
a very interesting part of the system or maybe because it's an urgent bug fix
or a huge deal is riding on it for my client -- I can do detailed technical
work for considerably longer without suffering a drop in either equality or
productivity, but these are exceptional cases and in short bursts for maybe a
day or two at a time. It's not a level I can sustain for multiple weeks.

(Edit: To answer the question about contracts, if I'm billing on a time and
materials basis then my contractual wording normally says I can bill the daily
rate for any date on which services are provided, without reference to how
exactly I will provided the services or any specific hours or number of hours.
Sometimes this raises eyebrows when people first see it, usually if they are
used to working with other people who bill by the hour. However, my experience
has been that no serious prospect objects to the point of losing a deal over
it, nor has it created any lack of trust or bad feeling once a client sees how
it really works. In practice, I sometimes work only a couple of hours in a day
because something has been held up on my client's end, and I think my record
was something like an 18 hour day involving significant travel, and I would
charge the same for both. At some point you just have to be sensible about
these things and trust that it will work out fairly overall.)

------
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.

------
rmcastil
Another way to approach this is to ask what they consider a day to be? Is it
sitting in the chair from 9 to 5? Is it just doing a certain number of
features in a day? Does it involve doing support after hours? Considering that
they are asking for a 'day' rate I'm assuming this is their way of asking if
they can retain you for full time work the extent of the contract.

In these situations I make it clear that while I'm willing to make them my
primary client my business does require me to attend to other matters such as
administration, taxes, billing, lead generation, etc.

I never say they can expect X hours out of me a week because quite frankly
I've never been good at maintaining a consistent hourly pace per week. When I
was doing hourly I averaged about 20 hours a week of programming (I was pretty
fanatical about starting/stopping the clock). When I would get closer to 30
that was when I would be pushing a deadline or getting close to burnout.

What I do now is get a sense of what they expect out of me in terms of
reliability and production. This tends to be a lot of work up front because
I'm building trust with the client. Such as meeting with them more frequently
to get on the same page as them. But that up front work pays off dividends
later on when I have to bail to attend to family or business matters.
Eventually this settles down to weekly communication to see if you're actually
meeting/exceeding the client's expectations.

Again I'd emphasize asking more questions about what they consider a day to
be? Who knows it might just mean you working on their stuff for 5 hours a day
:)

------
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.

------
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.

------
h1d
As others have pointed out a programmer's day does not involve only typing
keyboard. If you do that 8 hours straight without thinking, it'll be as good
as a pianist randomly typing keys for half of the time.

A good programmer should think forward in time and type rather less, coming up
with a good logic and analysing problems take as much time as coding that
thought into programs.

Also, when you do think for a long time, brain naturally needs rest, so if
you're like me who can work alone, you can find out your best pattern, such as
work a few hours then throw yourself on the bed, play with your phone etc and
come back when your mind feels straight.

This makes me think the other thread with a poll mentioning how people are
only productive for 2-4 hours a day kind of makes me wonder... Sure you may
have to be at office for 8 hours and you could be productive for less than
half of the time being there... But right now when I'm behind schedule from
multiple clients, I work the whole day, even splitting the sleep time into 2
times for 4 hours, working only when my mind feels straight, I can definitely
do 8 hours plus of decent quality work and do that for days until maybe once
every 10 days I'm used up for most of that day.

It's definitely not easy for office workers to do same.

I work alone at home against multiple clients I know locally and if I'm
assigned a whole project, obviously I quote for the entire project, so I may
get lucky and go well as hourly basis pay but for assignments that are only
tasked to fix small problems, I just give them quote of roughly $300 a day.

Try to think how worth your day can be when giving them quotes. If you're
inexperienced and needs lots of time googling around, you should lower it and
consider it a good chance to learn, not earn but if you're very effective
against their problem for most of the day, give them a good one.

Also, don't start from lower point, because raising later considering it just
won't cut it will raise their eye brows. If you ever feel you quoted too high,
it's a good motivation to work more as well and make up for it.

------
gauss156
Maximum 10 hours, but I'm usually drained afterward. That's only if I'm in the
middle of a big push, like for an MVP or something. Average is probably 6
hours, assuming the requirements are well defined and I know the language and
system well.

For poorly defined requirements, a language I don't know, or any other
"bullshit" variables, tack off two hours per bullshit variable. Hence if there
are 3 or more bullshit variables, my productivity effectively goes to 0. (A
bit tongue in cheek of course; really one should take responsibility for one's
productivity no matter how much bullshit.)

------
shawnz
Here is a recent poll asking a similar question:

[https://news.ycombinator.com/item?id=7657502](https://news.ycombinator.com/item?id=7657502)

The most popular answer was 2-4 hours.

------
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.

------
afro88
In an 8 hour day I can do 5 hours productive programming, using the pomodoro
technique in 4x30min blocks followed by a 30min break. Keeps my head focussed
and fresh all day, and I'm not wiped out at night. There's a huge difference
in my productivity on days I strictly follow pomodoro and days I just continue
programming until I literally need a break.

Edit: I charge 1 day for these days. I get more than a days work done compared
to other people in the office, so I feel it's fair.

------
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.

------
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...

------
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.

------
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.

------
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).

------
marketingadvice
For freelance work I take the number of hours I will likely sit and then
multiply by 75 - 85% depending on if I feel good about the project (can I
enjoy it). That way I account for random Reddit/HN checks, email reading, TV
watching, and any other distractions.

------
pranaya_co
Probably no more than 3/4 hours. After that, I find that the quality of code
goes down significantly. Of course, this would be different if this 3/4 is
spreadout throughout the day with other "filler" jobs in between.

------
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 :-)

------
djent
I can probably program productively for about 1.5-2 hours a day, all in 10-20
minute bursts. Right now, I'm a student and focused on learning languages
rather than completing projects for money.

------
__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.

------
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.

------
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.

------
digita88
For me, it'll be around the 80/20 rule. Meaning that, 20% of my working time
will most likely end up being useful to 80% of my work.

------
LeicaLatte
My Wakatime reports about 4 hours of Xcode per day.

~~~
welder
This is interesting. I'll generate some stats on the average time
[https://wakatime.com](https://wakatime.com) users program each day.

------
vemuruadi
5-6 Hrs is good for programming for a day, productivity goes down if we
stretch.

------
magnet1c
I estimate 5 hours is my max without quality loss.

------
mundanevoice
5/6 hours max on a good day.

------
walshemj
a really good day with no outside interruption interruptions 5 hours would be
my guess.

------
marutib
5-6 hours I think ?

------
Ad_Nauseam
20 minutes.

~~~
collyw
20 minutes is what I realistically achieve, with the amount of interruptions
and stuff I receive. I used to get most of the 8 hour day being productive a
long time ago (when the organization was just being set up)

