Ask HN: How many (actual) hours do you work a week?

Thinking back to years ago when I did individual freelance work, I would say you are actually doing quite well to get in 30 billable hours. Realistically you probably need to spend 10 to 20 hours a week on all the ancillary tasks (especially doing work that will get you more, better, future clients). So if you want to have a long-term sustainable result, it's probably best to plan on at most 30 billable hours per week.

(Of course, people who can disregard or don't have families and other obligations, could plausibly work an enormous amount of hours. But that doesn't seem like a great strategy, there are so many good opportunities to produce a lot of value and receive reasonable pay for reasonable total work.)

Bad news: it's unlikely you can work longer hours productively.

Good news: working more hours is the least effective way to be more productive.

The key to productivity is reducing unnecessary work. That means:

* Things you think the customer wants, but actually they don't.

* Things that are nice to have, not on critical path to success. Sometimes the customers thinks they want them, but often they won't care if they're not actually there.

* Things that are "best practices" generically but not applicable in particular situations. E.g. unit tests if this is code that will never be reused and you have an end-to-end test.

* Digressions where you go off on a tangent and realize too late. This can be solved with timeboxing.

I could go on. In general it's possible to be far more productive while still working same number of hours.

More suggestions here: https://codewithoutrules.com/2016/08/25/the-01x-programmer/

More conceptual overview here: https://codewithoutrules.com/2017/10/04/technical-skills-pro...

Interestingly, being more productive as hourly contractor is a bad thing mostly, since you get paid less. Working fixed contracts is better that way.

In this particular weird setup your company has, though, sounds like that's not the case. But as others have said the system they use doesn't make sense.

Bill by larger time blocks (days, weeks?). Done with your work for the day in a couple hours? Take a walk in the forest, do some fishing, work on your car, meditate or whatever.

I don't know. I've never tracked my hours, despite working contract for most of my career.

Based on managing contractors for years now, I think you might be the most honest contractor I've ever heard of. Most of them bill for more hours than they're actually coding. I don't think this is malicious -- it's simply replicating the salaried structure, where goofing off and Facebooking are still part of a work day.

If you feel like you're pretty efficient, I think fixed-fee projects are good for both parties. Hourly tracking is pretty miserable. My clients are usually excited that I offer only fixed-fee engagements.

If you do continue time-based billing, you should try to switch to weekly or monthly instead of hourly. This allows you to build in a little variability.

Somewhat unrelated: someone posted on HN that s/he only codes 4 hours a day at the most, because most people's brains only have a certain amount of cycles to devote to something truly thought-intensive. Many, many people chimed in with their agreement.

That's an anecdote, sure, but there's lots of research to suggest that much more than 30 hours of productivity per week is a fantasy.

> Most of them bill for more hours than they're actually coding.

I pretty much figured that. Problem is how we manage our internal work flow is based on tickets with an amount of hours allocated to each one. Some have 4 or 8, others have 40+. Many times I am given 3 or 4 four hour tickets to tide me over for a couple of days (while some bigger tickets are negotiated), but trying to get those 4 four hour tickets done takes all week (or sometimes more). I've stopped really caring if I overrun the times, but the main issue is these smaller tickets branch out across many different apps, all with their own quirks and there is a 3+ hour ramp up time just to get familiar with what the ticket even wants me to do. Then you end up with the dreaded "Why did it take 8 hours just to add a button to a page?" scenario.

Reminds me if this video:

http://www.dailymotion.com/video/x2gp98t

It sounds like the problem is that your org's internal workflow depends on accurately estimating the time things will take.

As any experienced coder will tell you (and you've just told me), time estimates for tasks are nonsense. You should never run a team by relying on time estimates because they will always be wrong and people will be unhappy (both clients and employees).

Yeah at the very least you should have gotten a rate hike when they changed the way your hours are calculated. You are now taking on the risk of the extra complexity of the project, which was previously on them. They should have to pay for that.

It is unfair for them to not allow you to bill for the 3+ hour ramp up time. A couple possible ways I could think to resolve this: 1) You could start pushing back immediately on the issues that you know are unrealistically allocated. Point out that the change is across different systems, or any other amount of complexity. 2) You could start tracking your time on each individual issue. This includes ramp up time, tracking your time for the project, emailing back and forth, or any other overhead that goes into the ticket. At the end of the sprint you could go to the manager with it and say here is how the actual time spent differs from what you told me it would be. 3)Start looking for a client that has a more sane workflow.

> It is unfair for them to not allow you to bill for the 3+ hour ramp up time.

This is just one case of many (where I loose hours/money), but to elaborate; say I get a ticket for 2 hours, "Just add a delete button for an order item on a form". Sounds sane, and I even agree that it should only take 2 hours. But of course once you get into the code you find some snags. After two hours of digging through the code you realize why the delete button was never added in the first place (was not a simple task).

But either way, I just spent 2 hours reading code, and still have another 2-3 hours of coding left to do. Might take a break at that point and collect my thoughts, get something to eat, might get side tracked then and not get back to actually working for another hour or 2. Then code up the feature. So that's 7 hours+ right there. Then I bill 2 or 3 hours for that, but it took all day.

Boss is normally understanding of going a little bit over (though not really for going 150% over). But really the end customer that pays for the work is worse to deal with. Half the time if they think something (even if it is a "fix") is going to take longer than a couple of hours, they just won't bother with authorizing the work. Then we end up with a big wart in the code base that we have to work around constantly (which in many cases, refusing to pay for an 8 hour fix has caused 100's of hours of other issues.. but another issue)

So I guess I feel guilty about working 7 hours on a 2 hour ticket when I know the end customer will just throw a fit. I guess I should just start billing for those hours in this case. But it feels like it is my fault. If I could just remember the internals of the code base, I wouldn't have had to spend two hours just reading code. Seems reasonable.. but maybe not.

Most of them bill for more hours than they're actually coding. I don't think this is malicious -- it's simply replicating the salaried structure, where goofing off and Facebooking are still part of a work day.

I am a 1099 contract developer and I definitely bill for non-coding time. If there is a bug and I have to read stackoverflow for an hour to fix it, I bill for that hour. You want me to do a code review on your in-house developers' tickets and it takes an hour, I bill for that too. I build for time spent running tests, submitting PRs, merging code, deploying, and updating Jira. I bill for meetings and phone calls, I bill for emails, I even bill for time I spend billing you. 30 hours of coding can easily be 50 hours billed.

> My employers are starting to complain about needing more work from me (ie, put in more hours).

> Problem is I simply don't have any more time to give.

This sounds like a classic employer move. Of course they want you to give them more of your time.

What do YOU want? Why do you want more than 30 hours a week billable time? Could you raise your own hourly rate that you charge your employer and work the same or fewer hours?

Considering they equate estimations of hours on tickets w/ hours you work and bill, all hope is lost. A dev shop should know better. The fact that they don't is disheartening, and makes me think management level is not run anyone w/ software dev experience.

The cynic in me says that you should just pad hours on ticket estimations to encompass ancillary tasks and bill for 40 hours while working the same as you do. It's a bit dishonest, but you may end up with happier management, and a happier you.

Wow, what a backwards company. This reminds of how IBM used to measure productivity of programmers by the number of lines of code they've written.

Everybody knows that there is much more work involved in programming than just typing characters into an IDE. I've never heard of any programming contract jobs that were as strict on hours as this. Whats stopping you from leaving and explaining exactly what you just wrote to the client? You are getting a very bad deal.

> Whats stopping you from leaving and explaining exactly what you just wrote to the client?

OP was probably broke before the job and is worried about having income.

True, if you are not in a position to risk leaving this job then I suggest you save up at least 3 months worth of living expenses and then quit. Bottom line is this company is screwing you over.

Personally, I really like my coworking space. But I got one that's 10 minutes away. Isn't there something closer to you?

Also, I have the feeling that you're overthinking this. Sit down at 08:30. Grab a brownbagged sandwich from 12:30 to 13:00. Then work until 17:00. Done, go home and enjoy your spare time. This business of sitting in your office until 12:00 PM sounds ridiculous to me, why would any wife out up with that?

>Personally, I really like my coworking space. But I got one that's 10 minutes away. Isn't there something closer to you?

No, I'm out in the sticks. Hence why I fancy remote dev work :)

>Also, I have the feeling that you're overthinking this. Sit down at 08:30. Grab a brownbagged sandwich from 12:30 to 13:00. Then work until 17:00. Done, go home and enjoy your spare time.

I'm really trying to do that. Problem is a few hours time zone difference between me and my workplace. They are ahead of me. So what usually happens is I constantly end up staying up late in order to get them something they can test out in the morning (before I sign back on) that a way when I came back the next day for work, I will know whether what I did the day before is working or not. But I guess that is not working...

>This business of sitting in your office until 12:00 PM sounds ridiculous to me, why would any wife out up with that?

She manages, but doesn't like it...

I think you may be making incorrect assumptions.

Are you sure that you need to be working more hours? Based on the setup you have, it simply sounds like you need to be accomplishing more. The actual number of hours it takes to complete a ticket is irrelevant (if I understand correctly).

itamarst had some good things to say about increasing productivity.