Ask HN: Can one be self-employed fixing bugs?
By far my favourite software development task is to fix bugs.
Investigating, documenting, and fixing the root cause of a nasty bug has the ability to keep me in a mental state of flow for a full working day (and probably more).
Thus far in my career I’ve been employed, but I’d like to give self-employment a try. I’m not looking to create the next unicorn, just earn enough to become financially independent sooner rather than later.
My question is: can one be self-employed fixing bugs? If so, what are some effective strategies to make it a reality?
70 comments
[ 2.7 ms ] story [ 137 ms ] threadhttps://github.com/fossjobs/fossjobs/wiki/resources#bounties
Another approach would be to become a consultant either in security/pen testing or in some specialty quality area where you have a network of people who know your ability and would contract with you to get started.
Bluntly (because I think it's helpful): I don't expect either of those would accelerate your path to financial independence versus just working for a company who values software quality and has a distinct track for employees to work in that area. ("Punching a clock" is also a lot less stress than selling your services.)
Or start a blog and post about all these nasty bugs you're fixing in detail. Make a name for yourself as the person who figures out difficult bugs. Add a contact section listing the type of jobs you like and your hour/day price.
I don't have much experience with QA jobs but maybe that's also an option if you want to stay permanently employed. I'm sure a QA engineer that finds AND fixes bugs would be appreciated.
One difficulty with being self-employed for this particular kind of task is that the more you know the environment, the better insights you will have. That's already difficult if you've been at a company for many years... I can imagine facing a bug without a lot of context might make it difficult to troubleshoot initially.... but it's also an opportunity: these clients will want to keep you around to leverage that knowledge you built about their environment.
Do you mean the freelancer job boards like Upwork, or something else?
Heck I might do this myself for some extra side income.
Your personality is also one that I would fight to get on our team.
I helped my department found a "Mathematics of Finance" masters program, teaching numerical methods for the first three years. Three guys were trying to combine all their courses for an omnibus project that would get them dream jobs. They were coding a never-implemented research paper in C++. Sensing my finance background was thin but I was good at programming, they arrived at my office hours to describe their failing code.
I didn't understand a word they were saying. Keeping a poker face, I was sinking into depression. "They pay so much to be here, and I don't know what I'm doing. I've got to think of something to say so they'll just leave. Happy, but please, just leave."
Then I heard a catch in their voices, as they described inserting a fractional time step between program phases. I jumped up, "No! You don't have to do that!" I proposed an alternative, asserting this could be their bug.
I got an effusive email message that evening, and they came back two more days. Now I knew the drill.
Ever notice how one is aware of cooking mistakes as one makes them? Code is the same way, one often hears the mistake as one makes it. And it's easier to hear in others.
All in all - good niche idea, if you can find how and where to market it.
Fixing the bugs is the easy part; finding customers and convincing them to pay you to help is the hard part.
Fixing the bugs is the easier part; finding customers and convincing them to pay you to help is the harder part.
FIFY: $10 please.
Perhaps look for prior art on being a third party/contract SDET or test/QA engineer?
I suspect you’d need to look for a specific class of opportunities where you can work on bugs under contract for customers, or, look for things where you can work on bugs externally as a third-party on public products and services, things like chasing bug bounties.
With many companies trying to abolish more traditional quality controls for software, by having developers conduct more test driven development, self driven integration testing, etc., I am not sure if you can be as successful as an external third-party offering bug fixing services, unless it’s in the right circumstances.
I am familiar with the concepts, but I'd classify that as more about putting measures in place to prevent bugs from being deployed, rather than identifying and fixing their root causes.
- What's the size of a bug that is worth the (never small) dive to the codebase/dev environment setup? The big ones are especially interesting for #1. For small bugs, it's not worth it for both parties.
- A single project will probably not generate enough work. Juggling multiple projects is a risk for everyone involved.
Sounds cliché but an employee is expected to 'create value' which has a variable meaning. As an employer - sure I have bugs for you to fix. But I also need new features, performance improvements, re-work old code, etc.
It's going to be a hard sell to hire someone who can only do one of those things (albeit very well), because employers expect someone who can adapt and can deliver whatever is reasonably asked of them in their domain.
I think you are also downplaying the importance of context, a contractor coming in fresh will be missing critical pieces of information that may influence why something happened or was designed like it is.
Bug/Security bounties sound to me like the closest alternative for what you are trying to do.
It's very possible they got burned out by the constant death marches for more and more features and never addressing any tech debt along the way. Many programmers can relate to that.
I as a senior programmer would like just one such gig in my life as well, to be honest. But seeing that decision-makers like you misinterpret it as "You can only fix bugs and not do anything else a programmer does? No thanks." fills me with despair.
I sometimes dream of becoming a highly paid Code Janitor that swoops in and saves your organization from starting over from scratch.
But I don't see a way to get into that field. For one thing, it doesn't even seem to be an existing "field".
As a former freelance developer, I think you might be able to make this work. I would guess that:
- You'd need to do a lot of work to find clients and build a reputation. "Fixing bugs" is a specialized niche.
- You'd probably work on lots of small projects, which means lots of deal closing and high daily/weekly rates.
- You'd need to look for projects in severe trouble.
- You'd need to fix not just the bugs, but the underlying organizational processes that are causing the project to be buggy.
But if you're willing to write articles about debuggung, set up automatic bug reporting tools, collect bug metrics, and teach teams to do 5 Whys/root cause analysis, I think you could probably find a market out there somewhere. There are always buggy projects in trouble, and some number of companies would pay an expert to help save an important project. You'd still spend half your time running the business, not debugging (or even training people to debug).
Of course, there are probably much easier ways to make a living as a freelance software developer. But if you enjoy "debugging" organizational issues as much as you like finding software bugs, there's probably a market here.
First, you need a significant amount of access and context on any codebase to be productive. Unless you're promising them a long-term commitment (and at that point are you really freelancing?) they might be hesitant to invest in fully training you, getting you credentials, etc. It's more likely that you'll get a niche project that you can work on independently, somewhat detached from the main project.
Second, even if you do build up enough context to work on big bugs, their causes are rarely shallow. What if you find a need for a major refactor or technology migration? As a freelancer, you have limited stakes in the process. So pushing your solution will involve playing all the normal politics, but as an outsider without any leverage. Hope you're convincing and enjoy lots of meetings.
Third, sadly, bugs just are not prioritized in today's product-led software environment. Existing employees are likely staring at their own backlog of bugs that they would love to fix, but which have been de-prioritized to push out new feature work. If (big if) a bug becomes a priority, full-time people with the most context on the problem are going to be doing the actual work - probably in a hurry. So freelancers are more likely to pick up the slack on low-priority feature work while the core devs are putting out fires.
I think this aspect can be overstated, or at least it varies a lot depending on type of project.
A while ago I was hired by a small client to fix a serious and tricky bug in an iOS app. I have never written an iOS app, I use neither ObjC nor Swift regularly, and at the time I had never compiled an iOS app and didn't even own an iOS device (though I did have a Mac to hand). But the bug was in audio processing code and I know that field quite well. They gave me access to their code repo, I bought a cheap iPad, I spent a few billable hours getting the app running, fixed the problem, a couple of rounds back and forth with the client to establish that they were happy with it, and done. It genuinely wasn't a trivial bug, but the investment in time on the client's part was perhaps one person-day and the entire exchange was over in a week.
Had the client been a bigger company and not just another indie, in theory I could have charged an arbitrary amount, as this was a revenue-threatening bug. But a bigger company surely wouldn't have hired an outsider to do it. An example like this suggests to me only that the problem is commercial or organisational rather than technical.
That's exactly right. Most businesses (including freelancers, the original question) fail based on their "commercial and organisational" success. If you want to come into a project and be the bug fixer for hire - you'd better have technical, commercial, and organizational success in mind. Fixing real bugs means fixing business problems, and no one is going to make inroads on technical terms alone.
So if you have a module with a bunch of bugs, I could see throwing a contractor at them - after the first couple they'll probably move pretty quickly.
On the other hand, if your bugs are scattered completely separately, then sure, that's gonna be a bad time.
The problem is they are the kind of bugs people don’t even know about, which makes it tricky for you to solve. And they only ever want it to be found.
They sell solutions to customers and when they determine it’s a software fix needed, they call you in.
You will need to bill this out at rates that at first seem absolutely insane - $3k a day perhaps - but when you’re called they’ll gladly pay and you won’t be called all the time.
When not active, do bug hunting in open source or soemthign.
For instance, in France a lot of freelancers are currently considered like "disposable employees": this borderline legal (your client is not supposed to have a subordination link on you) but as there is a real lack of candidates, that's what the market is going currently.
However, in your case these gigs might what you are looking for: 6+ months long-term contracts, working on already rolling projects, with lots of bugs to fix nobody want to fix internally because not sexy enough.
My strategy would be to look a job offers, and offer consulting services instead of full-time. You never know.
I've made more fixing them than the 'developers' have made selling them.
It's very lucrative for me, but I don't think it'd be viable as a full-time gig though.