4 ms·
Now the question is: did you make your client pay for each request _just as if you didn’t build such dsl_? In my experience, most developers-as-consultants are
by alanfranz 3y ago
Now the question is: did you make your client pay for each request _just as if you didn’t build such dsl_?
In my experience, most developers-as-consultants aren’t good at that. So, when we’re (rightfully) late, we probably reduce our margins. When we do a great job, we don’t make the client pay for his own mistakes.
- jimvdv 3y agoYou are right most developers are not very good at that. I think it’s important to stress that this goes both ways. You should not cut your margins if you take longer, but I also think it is a little unethical to bill more hours than one spends no? At least if you have a clear agreement to bill by the hour.
- awkward 3y agoThe way to ethically handle this is to have a clear and contractual minimum number of billed hours in a day. That will get you paid well for built in efficiencies like OP mentioned, and keep you paid fairly on more substantial change requests.
- thfuran 3y agoIt's outright fraud. It's clearly unethical. But your billing shouldn't be strictly hourly if you're building tooling to speed up your work.
- deleted 3y ago[deleted]
- derefr 3y agoWhat you’re saying is that it’s inherently unethical (to yourself!) to accept hourly billing for work the whole point of which is exponential automation.
- tshaddox 3y ago> did you make your client pay for each request _just as if you didn’t build such dsl_? I'm not exactly sure what you're asking. Should you be charging clients for time that you didn't have to spend because you made some good decisions upfront? That strikes me as odd. If you agreed upfront on the cost for a certain end result, then sure, charge that full agreed-upon amount even if it took you less time than expected. But it seems odd to say "this change only took me an hour, but it would have taken 10 hours if I had made worse choices in designing this system, therefore I'm going to bill you 10 hours." After all, there's always a hypothetical situation where any given change could have taken arbitrarily more time if you had made worse decisions in the past.
- xelxebar 3y ago> Should you be charging clients for time that you didn't have to spend Yes! Completing a job or task in 1 week is more valuable than completing it in 5. The lion's share of value we provide as developers and consultants is not output but battle-tested intuitions that let us navigate the giant solution space, so bad decisions we don't make is definitely hard-earned value servicing the client. A man once interrupted Picasso at his evening meal. Pulling a napkin from his pocket, the man said, “Could you sketch something for me? I’ll pay you for it. Name your price.” Picasso took a charcoal pencil from his pocket made a rapid sketch of a goat. It took only a few strokes, yet was unmistakably a Picasso. The man reached out for the napkin, but Picasso did not hand it over. “You owe me $100,000,” he said. The man was outraged. “$100,000? Why? That took you no more than 30 seconds to draw!” Picasso crumpled up the napkin and stuffed it into his jacket pocket. “You are wrong,” he said, dismissing the man. “It took me 40 years.”
- beachy 3y agoThat tired old Picasso story only works because the customer was not told up front how long the job was going to take. As a consultant, you are typically billing by the hour (or day) and you will most likely be giving the client some kind of estimate/quote as to how long the job will take, and your rate, and hence the cost to them. You might very well be able to do the job in one week rather than 5, but it would be dishonest to tell the customer it will take 5, then complete it in 1, but still bill them for 5. Instead you should tell the customer that it would normally take 5, but you are able to do it in 1, so you are charging 5x (or 3x or whatever) the going rate.
- ashton314 3y agoI was a student working as a web developer in an on-campus dev shop, and our client was one of the entities on campus. Thus, our incentive was to get a working thing as fast as possible that took as little maintenance as possible. I got bored on the job occasionally, so I'd try experiments on how elegantly I could implement something.