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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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?

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.

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.

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.

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

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.

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

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.

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.

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.

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

Here is a recent poll asking a similar question:

https://news.ycombinator.com/item?id=7657502

The most popular answer was 2-4 hours.

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.

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.

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.

Yeah this guy knows what's up.

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

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?

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.

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.

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

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.

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.

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

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.

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

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.

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.

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

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.

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)

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

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

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.

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.

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.

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.

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.

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.

My Wakatime reports about 4 hours of Xcode per day.

This is interesting. I'll generate some stats on the average time https://wakatime.com users program each day.

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

I estimate 5 hours is my max without quality loss.

5/6 hours max on a good day.

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

5-6 hours I think ?

20 minutes.

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)