Ethics for Freelance Programmers | Hacker News Reader

Ethics for Freelance Programmers

mikecavaliere.com

91 pointsmcavaliere60 comments

An easy way to get out of the trap of having to intricately track your hours, and at the same time get paid more, is to bill by the day instead of the hour. All projects that you charge money for get a 1-day minimum. I've written a lot about this:

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

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

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

(and, like a hundred more).

I get a mail from a contractor about every other month telling me how much happier they are for having switched from hourly to daily. Daily should be your default.

(Advanced skill: daily->weekly).

I work for external clients, and when they get billed daily instead of hourly I just convert the hours into full days according to a 8 hour workday. If I worked lets say 80 hours on 20 days on their project, we bill them 80/8 = 10 days.

Of course in those 20 days I also worked on other stuff, worked for other clients etc.

It would seem totally unfair to me to bill them 20 days instead, so how would you handle this?

Even when I only have a single client and do nothing else, it would seem unfair to count a full day if I worked longer or shorter that day. Unfair to me if I worked longer, unfair to them if I worked shorter.

Do you not see the broken incentive system here? The more efficiently you work, the less you get paid.

Keep it simple. Write a proposal with an estimated number of days to completion and a total price tag for the whole engagement. This is not a fixed-price proposal, but it has the same look-and-feel as one. If you go over the number of days you estimated, you bill in additional day increments. If you go under by at least a whole day, you dock days.

It does not matter when on the calendar or the wall clock you get the work done.

This basic technique works just fine when juggling multiple clients. When you're managing multiple projects, don't deliberately bill people a full day for 2 hours of work (it is just fine to bill a whole day for 2 hours work if they're the only client you have during that day, and the project simply takes less than a day: you have a 1-day minimum), but don't obsess about tracking hours.

Real clients, the ones worth keeping, care first and foremost about determinism. They want to pay a predictable amount of money for something to get done in a predictable amount of time, and that's it. They do not care about you minimizing the number of hours you bill, unless you ask them to care --- and a great way to beg a client to care about minimizing billed hours is to bill hourly.

I agree that any time based billing has that incentive conflict, but how does it fundamentally change when increasing the minimal unit? In the end you have to balance your efficiency and quality with your rate.

For me there are many aspects of a project/client I try to select for before the billing increment. I would not turn down a cool project that sounds great just because they do not agree to daily billing.

I don't know if I would or I wouldn't because I have never had the experience of needing to back down on daily billing.

Yeah, of the clients I've had, none of them have cared one whit about how they were billed, only that they were billed a predictable amount.

"Do you not see the broken incentive system here? The more efficiently you work, the less you get paid."

Changing the unit of time does not change this. You're just making it easier for yourself to justify charging a full day even if it took you 2 hours. But you could just as easily apply your methods using hours or half-days or weeks.

If you're working 2 hours and charging 8, you should simply raise your rates, and for the next project, give a more accurate time estimate.

The first couple years especially, freelancers should be doing this from project to project. It negates the "broken incentive system."

I disagree that fake-work is as endemic to daily billing as it is to hourly.

Regardless, maintaining an incentive to bill make- or fake-work is not the only reason to avoid hourly billing. I have something like a dozen more arguments in the links I posted, and elsewhere on the site.

Isn't the larger point here that these larger units solve micromanagement problems without impacting the finished product?

If not, then why stop at hours? Why not bill by the minute or second?

The answer to why hours are superior to minutes is the same as why days are superior to hours. It's just a useful level of aggregation to mitigate tedium.

The more efficiently you work, the less you get paid?

True in the micro; false in the macro. If I deliver under budget and on time, I get more work from that client. Keep doing that and they find you more work. You get to keep billing, perhaps for years.

The advantages as a freelancer for charging daily are clear to me from your posts, but what are the advantages for clients that make it a reasonable sell?

It is an intrinsically reasonable sell. Your billing structure is your billing structure; it doesn't have to be a negotiating point unless you let it become one. I advise against doing that.

There are two reasons a company hires a consultant: They want expertise not available in-house, or they want a cheaper price than in-house. If they question daily billing they are looking for the later. You don't want to be a cost cutting measure.

Careful: there are lots more reasons than this why companies hire consultants, and a lot of subtlety to unpack in the first reason you gave.

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

I definitely agree with you. I was being a bit facetious, but I should also have said you don't solely want to be a cost-cutting measure.

First, like tptacek says, you don't have to negotiate this point, it's just how you do business.

More importantly, there are many kinds of clients for which billing daily makes more sense. These also happen to be a type of client you'd really want to have.

Basically any large enterprise company that is used to paying a monthly salary to programmers, wouldn't even care about these things.

I would usually tell clients "We bill X per hour, billed daily at 9 hours per day, which comes out to X per day" or something similar. I would actually quote the hourly rate because, at least in my market, this is the way everyone immediately judges your cost (and value). (This also depends on what exactly you're selling - for extremely high-end freelancing work, I'd probably quote the final price, since I'd rather de-emphasize price and emphasize deliverables, but for basic programming work you will be compared to other programmers).

You don't have to negotiate because they typically don't give a rat's ass.

I haven't done it a whole lot, but I have negotiated a few development contracts on the client side. The very last thing on my list was how the supplier was going to bill us. I had a budget I couldn't exceed and the primary thing on my mind is "can these guys do the job on time and to the quality we need?"

The last time I did this I went with the supplier who was 3x the cost of the low bidder because I was more confident that they could do it on time. I have no incentive to save money (it's already budgeted for) and a great deal of incentive to not look like a fuckup.

They don't care. They care about the results and the overall costs, not how you bill.

Minor nitpick. They care about results, a reasonable approximation of costs, and most importantly, the delivery date.

Those are the 3 points of negotiation. Or rather 2 points. If a client is asking you to compromise on quality to reduce cost or delivery date, walk away.

So 2 points of negotiation. How much it costs and when will it be delivered.

Whatever you decide on the costs, make sure you can 100% deliver on the date agreed to. If you're late by even a day, you will ruin the relationship. That isn't to say they won't work with you anymore, but the relationship will become more difficult. It's as if you lied to them, however unintentionally.

Always deliver on time.

As far as how you break it down and bill them ... they don't really care. I bill by the week, day, hour, and sometimes by project ... whichever suits me at the moment or whichever I feel suits the client best.

Would be interested in hearing whether anyone's successfully used that style of billing in engineering. I haven't heard of it being common/allowed at least in the oil & gas sector, though I haven't done any kind of big study of it. Of course, if you're bidding on a fixed-rate contract, you can internally account for your labor however you want. But if you're bidding on a cost-plus contract, the labor part of cost is—at least as far as I've run in to—expected to be in the unit "hours". RfP systems often even have that expectation baked in to the software. (You can add terms specifying minimum billing increments and such, common especially around site visits being billed in minimum 4-hour or 8-hour increments, but the actual quoted rate ends up being in the unit "hours" still.)

The kind of freelancing (consulting, really) that Thomas is referring to usually isn't the kind where you have to type numbers into an application to get paid. Usually it involves hand-shakes and emailing an invoice to the accounts payable department of your client and receiving an ACH transfer or check in the mail.

If technology is a barrier, I can almost guarantee they aren't happy about it either, and maybe they would like to have a conversation about the pain points of their outsourcing solutions. (Hint hint.)

Maybe we're thinking of different kinds of consulting. What I have in mind doesn't involve handshakes and emailed invoices, but usually competitive bids. They want some work done, and invite consulting companies to submit proposals. They choose a proposal they like, and if chosen you do it and get paid according to the terms. Usually somewhat standardized terms so they can reasonably compare the bids, and do some kind of oversight.

Is what you're describing similar to the eLance/oDesk/Upstart race-to-the-bottom that plagues novice freelancers?

If $300-500/hr rates are the bottom, then yes. :) It's not really new, though; competitive bids have been around forever. Many government contracts even legally require them, as a way of attempting to combat corruption.

Apologies, I've not gone down the government contract route yet (and I'm not in a hurry to travel that road either) so I misread the context as corporations doing a reverse-auction among competing clients.

A daily rate is very common among consultants in the oil and gas industry.

I argue a similar thing often -- we're all fundamentally driven by incentives, and hourly billing creates a direct financial incentive to work more slowly (and a financial disincentive to work more quickly), no matter how honest/honorable we want to convince ourselves we are. Even if it's the teensiest, tiniest, most subtle ping, there's a little ping in the back of your head that will always say "if this takes me 2 hours, I earn $200. If it takes me 1 hours, I only earn $100."

I know per-project billing is fraught with its own issues, but I'm much more a fan of that vs. time-based billing. It may work out to cost the client more, but it removes that layer of distrust ("is my engineer taking longer to squeeze more money out of me?") and sets the incentive on the worker to get the job done as quickly as possible, since now taking longer becomes the disincentive.

I believe the only folks who should bill hourly are the ones who do jobs where performance of work duties is directly correlated to hours spent working -- i.e. where doing a job "faster" doesn't change the time required. Security guards, retail workers, etc.

I'm sure there are a ton of fallacies in the above arguments, so let's hear 'em...

Having done both, I can say that I prefer the per-project method for the reasons above, but the problem there is when workload exceeds cost and time estimates, and it's either ask the client for more or grind through a project you feel is undervaluing you. Not a solution, just two cents.

I think this is a very reasonable argument for per-project billing, for the reasons you mentioned. But the downside you mentioned is valid also - that some clients will be greedy with your time.

I prefer time based billing, because I don't work 8 hour days like normal people. For this reason I also make sure I'm working on things that can be done in those timeslots, and I'm very, very conscious of the client's time.

I think either method is fine as long as you're comfortable with it, and you're on the same page as the client.

I often hear the touting of project-based billing, but the reason I'm afraid to make the jump is that in my field (developing prototypes, often novel, for scientific applications), the requirements are just not well-defined enough to give an accurate estimate. If I went project-based, just to cover the risks involved, I might have to charge 2x or 3x what it might actually take me. This may work if your clients are big corporations for whom 10k is the same as 20k is the same as 30k, but not when you're working with startups, boot-strappers, etc.

I know the next thing people will say is find better clients, but some people just have expertise in areas where the clients tend to be smaller and more cash-strapped. Thankfully the work is interesting.

Right now I give estimates, but still provide hourly billing as a safety net. Once I'm confident that my estimates are consistently accurate, I might move to project based billing, but it also feels a bit sleazy because what I would do at that point is just take ESTIMATE x SOME MULTIPLIER. In other words, project-based billing sometimes sounds like a hand-wavy way to charge the customer more without them being able to tell.

I don't think project-based billing is necessarily the right way to go. Most of the projects I've done have been time & materials.

I can't agree with this. I've never experienced the ping you're talking about, and I've billed many thousands of hours on an hourly basis. There's always far more demand on my time than I can fill.

This is probably the best advice I've ever taken from tptacek (and I've taken a lot of his advice).

Anyone who is billing by the hour is doing themselves a disservice, especially if they're not including "time spent on the phone with the g/f" or "time going to the bathroom" (true story - I really used to take out time going to the bathroom! Seems hard to imagine looking back).

I could write a lot more about this, but tptacek has already said it all so much better in the past. I just wanted to chime in as another person who totally agrees, and that actually transitioned from not billing "daily" to billing "daily" (or weekly or monthly).

That's very interesting. I'll consider that, thanks.

However, just today I did something that lasted around 3 hours. Probably closer to 2. It's a kind of work that happens somewhat regularly.

Charging a full day would be unviable. Way too expensive for the client. Perhaps charging half a day at a minimum? It almost never is just a single hour in reality. Advices are welcome.

2 options:

1. Get better clients. Seriously. The competition for clients who won't waste time reviewing rounding-error invoice differences is not that fierce. Of the successful consultants, most suck!

2. Package your services for clients that want you for 2 hours a week in the form of a retainer. "You can get 2 billable hours from me on X days notice, but only if you buy a quarterly recurring contract from me; the hours in that contract are use-it-or-lose-it. Otherwise, every time I take a contract from you, I lose 6 otherwise billable hours I could earn from another client due to ramp-up and ramp-down."

I'm not making it up: I keep hearing from people who have made this minor change to the way they sell work, and all of them seem extremely happy about the difference it made. It's a little tough for me to evaluate hourly vs. daily objectively, because most of my consulting experience has been daily or weekly, but I'll add to that: daily billing worked pretty great for me too.

In my entire working life I have not once needed a time-tracking package. That alone should sell you!

I'm not a consultant, I'm a programer and graphic designer. So there are times when I'm asked to simply restart a service on a server, make a few changes on a site or retouch a few photos.

It's not recurring enough (from single client) to justify a monthly fee. It's also an almost zero stress job, so it's hard for me to say no. Not the most stimulating work to be sure, but it sometimes leads to bigger, better projects.

But I agree that hourly charges are not a good dynamic for everyone involved.

Just to snipe patio11's inevitable reply:

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

How much value does a few minutes/hours/days of your time create for them? That's the only question that matters.

If you can consistently create a lot of value, it doesn't matter how much time you need to invest, you deserve to be paid for not only the time you've put forth, but also the potential time that you might need to spend fixing stuff if something goes horribly wrong.

"Oh hey, I can't get MySQL to restart." This 2 minute fix just became a half hour of debugging. Maybe you've discovered that the RAM is bad and the HDD is on its way out, now you have to plan and execute a server migration with a minimal loss of business. How many hours do you think that will take? (If you say less than 2, you are a superman; please teach me your ways.)

Clients don't care about these details. All they want is for a business problem to be fixed in a predictable amount of time for a predictable rate. These details are your problem.

Charging an hourly rate makes it their problem.

Even though it might not seem intuitive, you're doing them a favor by charging a day-rate and exercising your discretion whether or not you even invoice them for a quick fix. You're the domain specialist.

I'm familiar with the “don't call yourself a programer” mantra. But I have no problem with it, I quite like it in fact, it was a childhood dream and I'm proud of it, even knowing that I could probably make more money if I came up with another title.

Sure, sometimes an easy job becomes a nightmare like you described, but it's rare.

I fully admit that I'm terrible at estimating the value I generate. But I'm thinking of a more basic problem, that tptacek's comment succinctly described: an hourly rate makes you wanna take longer to complete a task which in turn makes your client doubt your capability/honesty. It's a bad dynamic that I'm willing to reconsider.

Good points Mike.

"Be honest about what you can and can’t do."

Yep. Got burned on this once in my short time freelancing. Got cocky and thought I could pull off implementing something in a technology I've never used under a fixed contract. Live and learn.

"Question whether you’re building the right thing – within reason."

I really appreciate this point. I deal with mostly non-technical clients who sometimes don't always know what they want. Being able to get to the core of what they're after and say no to things that would make me a lot of money but be useless to them is crucial.

Thanks dopeboy. I think we've all gotten burned at one time or another for that reason.

To me, the interesting bit here is that you have to be honest with yourself about your limits as well - and in particular, be very good about understanding those limits.

I think in this instance, ethics and economic incentives align - your expertise is part of your value-prop to clients, and having a good grasp of your limits makes you substantially more valuable. You get things done on-time, with clear expectations set, and do a prompt and thorough job providing what you're being paid for.

Personally, as a natural optimist, one thing I need to be especially careful about is not saying "yeah that's doable!" and setting expectations too high - it can potentially lead to a messy situation. That said, one of my favorite parts of freelancing is that I get confronted with new, unique challenges that I've never dealt with before - there's a balance to be struck here.

Back when I freelanced, I had the opposite problem (saying "no" too often), but I don't think it was my skillset or the project-type that was the problem as the author suggests. I have a real self-confidence problem that makes me pretty bad at freelancing. I've worked on that a bit, but in the end I ended up going back to FT work. I'd eventually like to give it another whirl if/when I can learn to get self-confidence where it needs to be.

Yet another site where the content is nothing but static text, but it doesn't even show without JavaScript. Fix this.

While solid advice, this is not really specific to freelancing. Perhaps the freelancing model offers more opportunities to violate this code of conduct, but that's it.

With some cosmetic rephrasing most of it would apply to developers with regular jobs just the same. Only your customer becomes your employer.

Okay, we're not paid by the hour, but don't we still "owe it to the [employer] to not burn their money unnecessarily", and isn't it still true that "time on the phone with your girlfriend" isn't what one gets paid for? (I'm not saying anyone is supposed to, or capable of flinging code for 8 hours straight - obviously not, the boundary is a matter of common sense)

Not to mention honesty, doing a good job etc.

I wasn't thinking about that while I wrote it, but yeah it's totally applicable for non-freelancers as well.

Yeah, I think so. But I agree that this sort of moral compass is probably more needed by a freelancer - more freedom, more decisions to make, so in this sense I can see why you'd qualify it as such, even if these guidelines are more universal...

I use Freshbooks with the Chronomate add-on. It lets me start a timer, pauses during inactivity, letting me determine to keep/remove idle time, and easily start/stop. It lets me document time in small chunks, so that each of those chunks shows up as a line item. Not the only solution like this, but I've found this combination to work the best for me.

Use something like the free http://rescuetime.com or http://manictime.com to track time spent.

Highly recommended whether working for yourself or a client.

I wrote up some thoughts on this topic since it's something I don't see often talked about.

Agree with the points. While billing hourly & tracking time on my own I tend to keep going back to the timer application to pause or start for every small occasion, depending whether I am working on the project or doing something else, even if its for a minute or two, coz distractions are omni-present & I can not work on something straight for 60 minutes at a time. That actually increases my anxiety.

So I much prefer to bill per work/project basis as a whole.

One thing regarding ethics, sometimes a client will want to 'copy' a feature they saw on another website, including the visual feature as well. That makes me uncomfortable, I try to make variations of it, although I have never denied work for this reason. May be next time I will atleast object strongly when its a blatant copy.

I think using a start/stop timer is selling yourself short. Almost every programmer has ebbs and flows between thoughts and output (e.g. writing code). When I take a brief break from coding to check my e-mail or something, it's not like I stop thinking about the program I'm working on entirely. I don't think I would be nearly as productive over the long term if I just stared at my IDE for all hours of work.

Often a solution to a bug that I was working on the previous day will come to me during a morning shower, and I think it would be ridiculous to bill for those kind of events. That's why I tend towards the conclusion that the breaks and what would be considered "observable, verifiable" work tend to balance out.

More years ago than I like to think about while I was working corporate, I threw together something to track my active window titles. That may not work to track vim in tmux, but I'd you're doing anything with website development it should give you a decent overview (which may also surprise you and motivate you to change your habits).

On Windows, Manic Time does a beautiful job of this active window tracking. I haven't found anything that does it for Linux, though.

There's tools for this like RescueTime. There's also Editor plugins like WakaTime that just track the time you spend on specific projects within your IDE. Not sure if they have vim options, though.

I'm wondering if there are freelancers out there who hire somebody to find new programming jobs for you?

I haven't tried it, but there are services like http://letsworkshop.com/ which are similar to what you're talking about.

> Clients pay us by the hour, and we tend to cost per hour more than permanent employees.

My clients pay me by the day. You lost me already.

"time on the phone with your girlfriend is generally not."

Maybe avoiding gender specific comment, should be part of your ethics as well?

And maybe avoiding obsessing about genderism should be part of general human ethics too? Just because 0.5 % of humanity is homosexual does not mean that we should feel guilty when using words like "girlfriend"

Social justice warriors never lose revolutionary vigilance!

Reply on news.ycombinator.com