Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Hourly freelancers, what do you do when you can't figure something out?
137 points by windowshopping on Feb 27, 2017 | hide | past | favorite | 70 comments
I'm stuck on a particularly irritating show-stopping bug (microchip's ADC functionality just giving 0 no matter what voltage is applied) and haven't been able to find a solution in days. I feel guilty continuing to charge for the many, many hours of investigation without producing anything....it's just making me feel incompetent and thieving.

Has this ever happened to you, and if so how did you handle it? Do you keep charging, or work for free, or just tell them "sorry, you have to hire someone else to complete this, I just don't know why this is happening" ?




In software development, when I can't figure something out, it's natural to feel "incompetent". After all, someone is paying you for your expertise and you can't figure it out. You dev instinct is to hide in the corner and avoid all contact until you figure it out.

But you have to put your business hat on. Communicate with the client from a business level - you've hit a snag and it's taking slightly longer than expected. The client will then ask: "How long will it take?" Because you can't figure it out, you have no idea. But the client wants a timeframe answer. I give the client usually a range of time like "give a day or two to figure it out" or "I'll let you know later on today".

Do not tell the client to go hire someone else if you value your relationship with the client. Find that "someone else" and pay them to figure it out if you can. Do not dump the "you go find another solution" on the client.


Find that "someone else" is probably the greatest business advice. It is good to keep contact with someone more expert than you always handy to reach out during difficult situations.


This is excellent advice.


I noticed no one mentioned what is, in my opinion, the biggest thing, and that's communicating to the client what's happening.

There's a fine line between saying "I'm stuck" and saying "I'm incompetent" so think carefully about how you say it.

And you're not incompetent for getting stuck, remember that.

It's all about making it clear they're still getting work out of what they're paying. And documenting what you tried and what's not working for the future doesn't hurt either.

It also lets them know when to pull the plug if costs are getting unmanageable (imagine how horrified a client would be finding out after budgeting 100 hours for a project that hours 10-100 have been spent on the issue they expected to take hours 10-20)


This. Give the client a set of clear options to choose from, as soon as you realise it's going to take longer than you thought.

One option is to timebox the investigation, like "I'll spend up to 10 hours trying to solve it myself, and then get back to you with more options"

I also give them the option of going fixed-fee for this part of the project, so I take the risk that I can't find a solution or it takes me a long time to find it.

This is absolutely normal, you are not a moron or incompetent for hitting this kind of wall. It can be hard to see past your own inner critic on this stuff ;)


Most clients pay for you to solve a business problem for them. Assuming you're sticking within legal/ethical confines, the how of how you get from problem to resolution is immaterial to the client.

As others have said, find someone who can get the answers you need, and pay them. Even if your margin is reduced a bit, you're still doing what the client wants and needs - solving their business problem.

There is no shame in asking for help. Should a similar situation present itself in the future, I'd recommend being quicker about asking for help, when you reach the point where you need it. :)


A few very important additions to this:

1. Appropriately communicate the snag to your client: you've run into an unorthodox problem, and will need a few days to investigate the problem, but you will keep them updated on progress.

2. If it turns out you missed something important and blew the time on a wild-goose chase, don't bill your client for that time. Sure, they might be none the wiser, but nothing builds relationship better than honesty: "I am not billing you for these 20 hours, because I spent them researching a problem and not delivering value."

For (2), clearly state that on your invoice.


I would say you're sending a clear message to the client with (2) that you don't value your time. Bill them from the moment you start to the moment you end. This is inclusive of all meetings and correspondence you have with them.

I highly recommend if you haven't look up consultation rates for Doctors, Lawyers, and Barristers.


Funnily enough, I am rather intimately familiar with legal billing.

Many, many years ago, I worked for a company that did semi-automated audits of legal invoices for global-scale clients. The number of times we caught lawyers billing full-partner rates for paralegal work was not small.

We made a very good business by pointing out that $1000+ per hour was a tad expensive for photocopying documents.

For a large legal firm, you can get away with this. As an independent consultant, your reputation, and the future success of your business, is based on the value you deliver to your client.

If you had to spend 20+ hours tracking down a tough bug because the bug itself was that ugly, you bill for that time.

But, on the other hand, if you blew 20+ hours tracking down a typo in the code that you made, you write that time off and credit it to the client.

This is, in part, how you show your clients that you are worth $X000 per day: because they are only paying for the time that you spend generating value for them.


Bill them for every single second of work. Perhaps it's because I come from a family of lawyers, but when that happens the customer simply receives a bill saying

Research: 40 hours.


I work in the legal industry and a lot of mark-down happens between the lawyer's work hours and the final bill at many different stages.

Lawyers track every second but they don't bill for every second. In fact, a lawyer might mark-down hours for the very same reason as the OP -- something has taken longer than it should.


Please god, more developers do this. Seriously worrisome some people are not charging the client for work.


I always explain at the outset that if I sit down and do something I would not be doing if you were not paying me, I am going to charge you.

I am not blessed with infinite time. I am not doing this for you because I'm a nice guy. I'm doing the work because you are paying me. That is the entire deal.

If you are on the fence watch this: https://creativemornings.com/talks/mike-monteiro--2/1


And if there's some compelling reason not to charge, for the love of god, make sure the hours show up on the bill, with a seperate row for credited hours.

You are doing your client a huge disservice by hiding hours you actually worked, even if you don't charge for them.


Hiding hours gives a wrong impression of how long a certain job will take and how much work is really involved. Same situation I see in large organisations and developers working long hours to get a project done because they've under-quoted. The employer then uses those metrics to measure future projects. Then when the employee's eventually burns out or start a family and transition into normal working hours the employer will see a sudden decline in productivity and assume they've been slacking off.

In the end you have the best intentions for your client but can end up making it worse for yourself going forward. Quote down to the minute you've been working on a project, if the client is un-happy then that is something you can work with.


The lawyer comparison is completely accurate but people shouldn't get too carried away without tempering it with the realities of the legal industry. You're billing correctly (like a lawyer) but may not be as valuable as a good lawyer.

If the problem you're solving is more of a general dev task, which 95% of tasks are then it's like a lawyer that is merely processing immigration paperwork. You're paying for it to be done right. Billing for research when you're writing CRUD apps is a good example of this.

If you're a Robert Shapiro or some hotshot taking on special cases, and winning, then you can probably bill for research. Billing for research when you're John Carmack qualifies here.

So I think the lawyer comparison is 100%. You should bill for every second. Just make sure you're not on par with the lawyer equivalent of needing to do research when building a CRUD app and you won't have any problem.


I don't agree with this approach. It's interesting but I don't see how the nature of the work you're doing disqualifies you from charging for "research" even when you're NOT a hotshot.

I think a better approach would be to charge per day.


I'd be pretty pissed off if I was charged a lot of money for "research" to have some lawyer file run of the mill divorce papers or immigration paperwork. It's like hiring a dev to build a CRUD app and he doesn't have basic competence either.

At a certain point, you need to a baseline competence or you shouldn't even be taking the job. If people balk at you for not being ready to even take on the basic job title, that shouldn't be a surprise.

I'm not saying if you come across a corner case that's special you shouldn't charge for it. It's like if you had an exceptional immigration case that required research, not just filing form 1072B.

It's something to keep in mind because you can lose your reputation or clients being silly with the "research 40 hours" act. Sometimes losing a little money today is a win longterm. A lawyer billing research for basic stuff or nonsense that no one else would (learning on the job, basically), would and should lose his clientele.


Not really, if a junior associate takes 40 hours to do what is conventionally accepted is a 10 hour job, it is going to be marked down, either by the partner or the client.


This is honestly a really funny answer. It might not be the right answer for me right now, but the lawyer bit is kind of hilarious.


I've been freelancing for ~7 years now, and at this moment I can recall one month-long bug that took A LOT of time to fix.

I like to imagine there is a certain "buffer" of hours, let's say a day or two of work, which you can use/are reasonable to spend on fixing bugs and issues. If I fill this buffer, I stop charging particularly for the time used to fix that bug. Again, it depends on the client, situation and how well I'm treated.


You don't have to ask your employer to hire someone else, you can do that yourself. Find an expert and pay them to diagnose the problem. If you get the right person they'll probably be able to work it out in short order and it won't cost you a fortune.


In fact, this is why they pay you the big bucks...you have the expertise to know when to call in a specialist. Like a general contractor remodeling your kitchen will call in a granite specialist to cut the hole for your undermount sink.


But how do you do that when you're working with custom-built hardware that you have the only extant prototype of?

I guess I can put up a freelancer-wanted ad and specify that we'd need to collaborate over skype. Basically I'd be hiring a consultant, I guess.


This is an aside, but whenever choosing a microcontroller I always read the Errata. You'd be surprised that TI or Microchip or whoever ships silicon with blocks of functionality that just don't work.

If I were you in this situation, I'd get on the phone with Microchip's closest field engineer, and maybe they can point you in the right direction, especially if this is a known issue. Perhaps they can connect you with engineering support farther up the chain.


Ha, not only that it doesn't work, but also that the datasheet/TRM/FUG says it's there and working, while the errata says it does not work and there is no workaround. So I fully agree, reading the errata is essential and should always be done before starting any implementation since the way you imagined to solve the thing might be totally off due to some errata issue.


When I used to do consulting, I never charged the client for me learning how to solve their problem. I always charged them for the time it took to actually solve the problem. So if I encountered something I didn't know how to do, or some problem I had no idea how to solve, I would learn or figure that out on my own time.

Some exceptions to this, for example if I am trying to unfuck something the client was responsible for, or they hired me specifically to solve this problem and I was clear up front that I would charge them for the time it took to figure out wtf was going on.

But let's say I decided to write a bit of Python code to solve a problem. And then I run into some obscure bug in one of the libraries I selected. If I can't figure that out quickly then I pause the project and switch to debugging the library and maybe even submitting a pull request, then I go back to the client project. Same if I need to learn some new library, or a new language, etc. If it's not the client's fault that I selected a library that had edge cases I wasn't aware of, why should they pay me to figure that out?


I consulted for 15+ years, now I hire consultant for my startup on the regular.

I billed for figuring it out, I expect those I hire to bill for figuring it out.

See, I hired you for a solution. This includes "unfuck"ing, figuring, learning and stuff. But, like everyone else is saying: the soft skill of communication is critical. A surprise bill of +5k is different than a "this might cost an extra $5k".

Also, perhaps unique but with 20+ years in tech many times when my the hired gun comes in with a sticking point I can point to both business case for trying a different path and a technical path forward too.


That's ok if you are fine with paying for it. To me the whole point of a hired gun is hiring someone that is profficient with the tools they are bringing to the table. And I bet outside of tech you would be really disappointed if your mechanic charged you for the time it took to figure out why their car lift wasn't working, or your contractor charged you for the time it took to troubleshoot their power tools, etc. So why is it so different when the tools involve software?


Note that I'm not trouble-shooting my own tools: the client custom designed the pcb this microchip is soldered to.


Are you using a dev kit to develop or using the client board? This is a pretty salient piece of information. If you don't have a dev kit, order one immediately. Microchip's kits are pretty cheap- make sure to get the in circuit debugger too if you don't already have one.


Agree for time spent learning new frameworks and technologies (i.e. generalist self-improvement that will be applicable to many clients and is part of your advertised skill-sets), but I would disagree on the example you've given (encountering an obscure bug during development).

Isn't this kind of learning really a discovery process inherent to analysis and development?

To take an old anecdote of the engineer who charges $1 for making a chalk mark and $9999 for knowing where to make the mark - if you're going "off the clock" while you work out where to make the mark (i.e. debugging a library), are you then charging higher rates when you "know where to make the mark"?


Yes, I used to charge much higher rates precisely because I either know how to solve the problem or I'll figure it out on my own time. This protects the client from the technical risk of the solutions I recommend, and that makes sense, because they are not technology experts. By me taking on that risk it forces me to be more careful about what technology choices I make. So I use tools that are battle tested, things that I've use do in production before and I know where the pitfalls are. I don't pick the new shiny thing just because I read 3 blog posts and played with it on the weekends.

When I hire a photographer to take pictures I don't expect to pay the photographer when their camera malfunctions and they are trying to format their SD card. Or if they just bought a new camera and haven't figured out how to adjust the white balance, etc. I don't see why hiring someone to solve problems with technology should be all that different.


I like the way you worded that! I have the same philosophy and I find it brings a rare form of sanity to my consulting projects.


First, communicate to the client that it's taking so long (and why its taking so long). They will ask for an estimate, and you can defer the estimate for a day or two. I bill my clients for 5 minute chats too - but for this one I would not.

Second, put a hard limit on the billable hours for such a thing. 30 hours, 40 hours, whatever you decide. Now you are in a better position to tell your clients their bill-estimate, but not a time estimate. If the problem is too hard, you could spend 100 hours in the week to solve it and only bill 40 hours - Might feel like being undervalued, but does not let the "guilt" build up. This also forces you to find workarounds to the problem because you are losing money now.

Third, hire somebody else at your own expense even if there are zero or slightly negative margins. I've done this in domains that I am not an expert. The thing is, you should be the go-to-guy(or go-to-company) for your client. However, if it's a frequent issue while working or don't love the challenge - you might consider moving out of such a domain.


Regarding the ADC issue specifically, when programming at the hardware level never discount the simple possibility that it's just that the microcontroller pin is fried (e.g. due to ESD). Also consider the opposite: the ADC is telling the truth, and there really is 0 volts. (In other words connect a multimeter or scope to the pin while changing applied voltage.)

There's also often mask/state/flag bits that can affect these things. Maybe the ADC is in differential mode whne you expected absolute, etc.

If I eliminated the easy possibilities and was stumped more than an hour, I'd go all the way back to a new/blank chip and whatever "My First ADC Demo" program Microchip supplied, possibly building it on a breadboard instead of the circuit board. If your real board can't start up without the rest of the project code, I would just frankenstein the breadboarded microcontroller on top of the soldered-in one. (E.g. connect ground and ADC lines only and see what the demo program reads there.)

Whether we're talking about mocks and unit tests for a web service, or hardware hacking, the process is the same: iteratively asking "How can I ensure I'm testing only one variable?"


I would recommend hiring your own expert to get through humps like this. You're going to save your time, resolve an issue quickly, also you'll know how to do it next time, and you still bill your client for the work (probably less than you taking the time to figure it out). Just invoice them normally by the way, typically you don't have to advertise you hired outside help unless your contact specifies or restricts it.

I can't justify charing my clients for large chunks of time figuring something out. Everyone runs in to issues that can take some time figuring out. I will invoice for that. If it's something challenging they requested reach out to them and say this is taking more time than I expected, can you ok increasing this to 8 to 16 more hours?

Also taking a break from a problem and coming back to it after a walk, shower or even overnight often times the solution will be there when you start back on it.

Good luck tackling this issue.


I keep charging until I either figure it out or they fire me.


I like this answer the best but the only snag with this one is you'll probably lose clients that would otherwise be reliable.


I'll generally research the issue thoroughly and then discuss options with the client. Communication is the most important part.

For one thing, depending on the problem and the client, the client may very well know others in the industry (it is their industry, after all) who can provide some insight. Sure, I could potentially hire someone myself, and if the client doesn't know someone, then that may be an option, but the problem could literally be resolved by a couple 15 minute phone calls or emails.

Maybe the feature (or method, or software, or component) isn't that important. Maybe there are other approaches that aren't as complicated or better documented or are just merely more expensive. Maybe there's a support team or original developer / engineer who can be paid for assistance. Maybe we can kick the feature down the road and get everything else done while we decide whether the feature is necessary or while we find someone who can help. Maybe there's a training program somewhere in the world that can be visited or invited[1]. Or maybe the issue is core and we need outside help immediately. Figure out the best options available and how much they're likely to cost (temporally and monetarily), discuss them with the client, and then decide together.

The most important point, through and through: Research Options and Communicate. You're being paid for your expertise, which is to say for what you know and for what you're prepared to learn due to your experience (and schooling), and part of that expertise is the ability to say you need help.

It's far worse and terribly unprofessional to waste valuable time and money getting nowhere than risk losing the project.

1: Story time: A friend's company recently gave a full-time employee two weeks to try to figure out a CNC router she bought from China. The employee is on a salary and it's their slow-season, so she didn't lose too much in letting him try. Unfortunately he couldn't figure it out, and now she's hiring an expert from out of state to come spend four days training her team. That training cost half as much as the CNC, but once her team understands it, they're going to make many times that per month. If I spent that much time trying to figure out that CNC at my daily rate, I would have far surpassed the cost of the router and potential profits within the first couple days - which would have been incredibly wasteful for all concerned parties.


Well, I figure it out. The Holmes Methodology always yields the answer. Maybe step away for a day and come back with a fresh head for examining the "impossible" reasons. Like you've got the input unplugged or the connector is glitching.


I'm in the same boat. The clients demanded that I work in Matlab so I worked in Matlab. When I work in Python or Node.js or Scala or R I don't have too many issues going from Unix to Windows or vice-versa. Matlab exploded, and it's not even a huge program. A few hundred lines!

Let them know what's going on. Did they pick the microchip? Then you aren't incompetent, you're fixing their issues.

Keep them in the loop. I like akulbes advice of subcontracting that problem out.

A hangup isn't incompetence. Having trouble with obstacles doesn't mean you're incompetent. It means you're pushing yourself. If you never push yourself you don't get better


I have a fair bit of Microchip experience, things to consider:

- You must set the AD1PCFGH or ANSEL bits to enable ADC functionality on a pin.

- There's nothing stopping you from accidentally configuring the pin as a digital output (it might even be helpful for some applications to measure the actual output from a digital output). Check the value of the TRIS register for that pin (and ODC register if it has it)

- Often there is a "Configuring Analog Port" section in the I/O Port section of the chip's datasheet.

Good luck!


I'm not sure if by "microchip" OP means MicroChip the manufacturer, or just micro-chip in the more generic sense.


Yes, I meant it in the generic sense, I'm sorry for the ambiguity. I didn't realize there was a manufacturer called MicroChip until this thread.


If you are working on sufficiently complicated projects it is inevitable that something like this will eventually happen. The way I have handled this in the past is to hire a sub-contractor.

Communication is key, especially if there could potentially be delays. I'm up front with clients in that I will typically discuss this possibility before begin working together. My basic contract has some language in it as well that essentially is saying that they are responsible for any fees that may be incurred by sub-contractors at the same rate we have agreed on.

The gist of it (and it is clear to my clients from the start) is that I have the leeway to hire specialists as needed without their consent so long as I'm only billing out at the rate we have already agreed upon. If I'm unable to do this, then I will have a discussion with the client and they would need to sign a contract amendment at the agreed upon rate.

So in general I will hire the sub at a rate that is less than my rate and actually make some profit off of this. The sub contractors I work with know I do this and find this a fair arrangement as it is a sort of "finders fee". The reverse situation has happened with some of these exact same people where I was sub contracting to them on an area where I had more expertise.


This is one of the issues with charging hourly, or even daily. Charge by value or weekly.


Forums and example projects are your new best friends. Always boil down the problem to the stupidest, simplest version and work up from there. In your case, it's a bare sample application board (see XPLAINED series from Atmel and various other equivicancies from other vendors... yes they're "expensive" but spending 200 bucks to get a demonstration / samples that run through all the functionality on the board is well worth everyone's time. Remember that 200 bucks is less than half a day billing, so it really puts things in perspective). Any small link failing anywhere results in a binary 0 success rate. Embedded stuff is absolutely brutal that way (see how often you confound ~ with ! and throw your computer at the wall after hours of straining eyeballs). Work up from examples. Work up from forums.


Always calculate the cost of engaging the manufacturer. Call them and ask them how much they charge for an engineer to help you. If you see yourself approaching what looks like it would have been cheaper to explain to someone and have them give you the result, take the plunge. Sometimes it is a manufacturing or design defect. Pay to learn, and ask the manufacturer for a refund if you really do find a defect. Don't ever tell the client you're unable to complete. Take a small loss, learn a small lesson, and deliver like a champ. They will think you did all the work, and with your new knowledge you will be able to deliver the same work for many clients in the future.


If there is no answer to the issue and you are an expert in the field, I would continue to charge for this research phase. The rationale about this is because you came up with a complex issue and every expert in the filed should take a lot of time figuring out why this is happening.

If you think that you can't came up with a solution because you are not a real expert at all, I would ask and pay one expert about this to pass this phase.

My company deals with complex issues all the time and I think the customers should be charged by this expertise because if not we are carrying with all the risk.


When I get stuck on problems like this for too long, I pause the troubleshooting effort and try to find other ways to be productive. This takes your immediate focus off the problem and lets your background mind work on it. Sleep on it. Then give a slow, thorough explanation of the problem to someone else who is unfamiliar. Doing so will often help you identify additional debugging steps you hadn't thought of, or to question assumptions you may have held onto unnecessarily.


You should inform your client of the situation then work together to resolve the problem. Best course of action might be to bring in another expert you know temporarily, possibly through subcontract if your client don't know who to hire.

Calling in another expert is not an admission of incompetence. It's just a matter of efficiency and expediency.

I'd not recommend doing what lawyers do. Best client-developer relationship is built-on trust. Follow your heart and you'll be rewarded over time.


Just one microcontroller? Could it just be a dead chip..?


Unfortunately all 8 pins are working perfectly for GPIO and DAC. Only ADC not working. However that doesn't necessarily prove that the chip isn't partially defective...it may indeed be a flaw with the ADC circuit pathways inside the chip. I may try to contact the manufacturer....I'm not sure.


If you don't mind sharing the chip name and the way you are using it, drop me a mail and I can try to help you. My user name at gmail.

Regarding charging the client. I usually give an estimate prior to the work. If I see the estimate won't be enough I usually tell them that something isn't as expected and that I'll need manufacturer's support. If they are ok with this we keep going.


Sent :) Thank you very much for the offer to try to help.


Please try visiting the EEVBlog IRC, there are many friendly people that might be of help. #eevblog at AfterNET


Have you successfully configured the ADC on this chip model before? I've been through the ADC docs for the PIC32MX/MZ many times and they're quite dense. It would be very easy to miss some required configuration bits.

In my experience, it's never a problem with the hardware itself, but you never know. I spent 3 weeks last summer debugging a problem with the MRF24WG0MA, and was almost convinced the chip was defective, until I realized that Harmony configured a few things incorrectly (the interrupt polarity being one of them). But yeah, for a show stopper issue that I'm not making any progress with, I would just get in contact with the manufacturer.


I don't think it's a problem with the hardware either, I'm just acknowledging it's physically possible.

No, I've never even worked with a microchip at all before. I do front-end web development normally. I am actively combing through the ADC section repeatedly, yes, to no avail so far.


I know how you feel. Dealing with hardware issues can be _extremely_ frustrating. It's very easy to dig yourself in a hole wherein you stop thinking clearly. In this situation, if you haven't completely given up on it yet, maybe take a day or two off and work on something else? I find that helps. Otherwise I would contact the manufacturer or post to their forums.

Feel free to email me if you want a second pair of eyes. sean at [myusername].com


Thanks! I already posted on upwork and took up one other person's offer in this thread. If neither pan out, I'll ask you next :)


* ADC enable register? * Reference level set? * Giving it ample time for a signal to settle? * Are you testing with a known input source? I would test first with a variable PSU and verify with a voltmeter externally to eliminate a possible second confusion.


Just do it. It seems thats all what you Can do except hiring another guy to identify your problem in this special field.

If it's possible, it is indeed possible.


How often does this happen? The truth is, it shouldn't be a surprise if occasionally/rarely you hit a road bump and can't easily get over it. Why not be up front about it, but also confident in your abilities, as evidenced by your work so far?

If this happens often, then I would probably recommend serious focus to get up-to-speed with the level of work your employer seems to expect.


If there is a bug in a level that your not responsible for you should just tell your client that there is a bug in xxx and you don't have a solution to get around it. Then the client should decide whether to spend time and tackle the bug ore replace the hardware or kill that feature etc. Hesitating consultation is the worst thing you can do.


If you're billing hourly, you're doing it wrong. You should be billing in advance for the value of the project to the business. Then their costs are fixed, and you are incentivized to finish quicker, modulo however long it takes plus 'figuring it out' time. See: www.expensiveproblem.com/hbin


In a situation like this, I contact the manufacturer. You can do it! Don't give up.


Thanks :)


try the simplest possible setup. measure the signal, is it in a range the chip supports? Do you have a faulty chip? try a different chip. Do you have a bad supply voltage? Bad components?


>I feel guilty continuing to charge for the many, many >hours of investigation without producing anything....it's >just making me feel incompetent and thieving.

Continue billing, be transparent, tell them you are doing work on a substantial, non-trivial issue




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: