Can one be self-employed fixing bugs?

A few things that make full-time bug fixing unlikely in a freelance capacity:

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.

You probably want to join a freelancer network and market yourself as a "troubleshooter, performance analysis, root cause analysis expert" or something like that. Start building a name for improving things and getting out. Limit your hours to short projects only. These platforms have recruiters that can help you find clients that are looking for that kind of expertise.

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.

I too thought about becoming a "code shrink".

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.

The FOSSjobs folks have a bounties section on their wiki that might he useful:

https://github.com/fossjobs/fossjobs/wiki/resources#bounties

Yes! Try Codementor (codementor.io).

I used their platform to work as an on-demand bug fixed for dozens of companies while working on my own schedule. At first, you have to build up relationships with 1:1 development help. It doesn’t take long to become familiar enough with your clients for them to ask you for your help on their trickiest problems.

The biggest issue (and the reason I no longer work there) is that the work is sporadic. Time spent fixing bugs is lost time you could have spent getting new clients, which leads to a sort of boom/bust work schedule.

Fixing bugs (even super hard ones) is a very narrow set of expectations for someone in software.

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.

Not really man. Others may encourage you here but I'm going to give you the realistic hard answer. The best thing for you is to target companies and do contract work there. There are tons of bugs to fix, they just only pay within a company :)

Really interesting question.

As primarily a maintenance programmer by inclination, I'd not ever given the possibility of self-employment a thought.

However, if you need to be paid, you need to create value. So the answer to your question is to find someone to pay you to fix bugs in software that 1) they use and depend on, that may not be well-maintained, 2) that you have the source and all dependencies for, and 3) that they would trust your expertise in understanding their requirements whilst being at 'arms-length'.

To be honest, it sounds a bit difficult, but you might try looking for support / developer roles. These are often unpopular with developers that want to do the new shiny, but there's lots of $$$ in keeping existing software working with updated APIs, fixing bugs etc.

Or you could be a framework evangelist / fixer on site. That largely matches my current role, where my job is to ensure that a large customer is happy, and utilizing our framework-type software to it's best advantage.

As someone with similar leanings, I used to wonder the same thing. I've been running my own company since 2001 and I've had a few engagements where I've been called in to resolve thorny problems for clients. In my experience, that work is inconsistent and based entirely on reputation. Additionally, bringing in another developer to fix a defect can cause a lot of friction with the client and is just generally problematic.

Management perspective: "These guys can't clean up their own mess. Let's go burn some more money with 0xf005ba11 to fix their screw-up."

Developer perspective: "I could have done exactly what 0xf005ba11 did if I just had a little more time and support."

>My question is: can one be self-employed fixing bugs? I feel like it's a lot of marketing and networking to get a day or two of work.

Even if you're amazing at it, I can't see how to manage a sales pipeline of just that.

Since no one has mentioned it, there are companies and numerous resources related to dealing with legacy code. Point this out, since in my opinion most likely person to fix a bug is person that wrote it — but at the point they are not, skills required to understand bugs are very similar to understanding legacy code. Beyond that, companies specializing in legacy code are able to offer additional services like updates, integration, migration, documentation, patches, training, etc.

Look at security bug bounty programs. All security issues are just plain old bugs.

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.

Don't sell yourself just as a "bug-fixer". Sell yourself as a lifesaver when a company has a terrible problem so severe that it emdangers millions in revenue, or even the whole company.

You can try cobbling together income from security bounties, but that's more on the finding bugs rather than going deep to investigate and fix them side of things.

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.)

You’d need to build a network of consultants who subcontract to you as a fixer.

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.

One of my friends/clients buys 'quality checked' scripts from Code Canyon, they're complete shit. Like even a beginner programmer wouldn't shit out this kind of garbage.

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.

I've seen many bugs that (because they had a workaround) were pushed away because nobody had the mental strength to open their specific can-o-worms or dig for their root cause. Someone who comes in just for those sounds like a sweet deal. Because in many cases fixing those requires understanding the whole working model of the system in it's whole, you now have established a relationship for future bug elimination. And the next bugs will take less time as you now have that mental model...

All in all - good niche idea, if you can find how and where to market it.

> My question is: can one be self-employed fixing bugs? If so, what are some effective strategies to make it a reality?

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.

Unsure about self employed, but there are definitely consultancies who specialise in legacy software maintenance https://www.legacycode.rocks/

I'm a good general developer, but what I seem to be much better than others in is refactoring legacy hell code into decently organized and workable code, without introducing bugs.

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".

Many companies have buggy code bases that need fixing or refactoring. It's essentially a one time job and once the heavy lifting is done, for an employed Dev the job changes a lot. So working on legacy code bases would work but maybe also offering to refurbish/consolidate

Probably some companies would be happy to offload the risk of a complex refactoring

Are you familiar with the concepts of SDET (software development engineer in test) or software test/QA? I’m asking genuinely because in our industry, traditional quality control sometimes seems to have went out the window in the rush for speed.

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.

This is how I started out as a contractor / freelancer. I got a call via my website to help a local company rescue a project that was suffering some problems having been worked on by not-so-great offshore companies. You may be well suited to and enjoy challenging projects. After 13 years however, I've got quite tired of a high percentage of projects that are hard for the wrong reasons, and correcting common avoidable mistakes. It seems to be that companies that hire contractors have something lacking in house (that's not true all the time by the way, there are plenty of other good reasons for using temporary contracts). It's been a great education in how not to do something, but now I want projects that are hard for more novel reasons.

The counter-question is: how good are you at sales and marketing?

Fixing the bugs is the easy part; finding customers and convincing them to pay you to help is the hard part.

From a product management perspective, one nasty aspect of bugs is that it's impossible to estimate how long it's going to take to fix them. (Because when you've looked deeply enough to know that, the actual fix is often not much additional work).

So, an interesting proposition could be to hire you and pay you a fixed rate per bug fixed, instead of an hourly rate. My core team can continue working on features, and I hand you a backlog of 10 or 20 bugs that I then get fixed at a known cost.

You would then take on the risk of how long you have to work to earn that fixed rate, but on the long term it would probably even out for you as well.

Might depend on your location.

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.

Honestly this sounds like a very nice niche. Put together a one-sheet sales pitch and start sending it out to businesses with an hourly rate and pitch, I'll bet you'll get some takers. It's a bounded task with a concrete outcome (as opposed to development which can expolode in cost and complexity sometimes), and its the sort of thing that dev teams would be comfortable outsourcing because most devs want to write new code instead of tracking down bugs. So, I would expect it to be a very attractive proposition to many teams.

Heck I might do this myself for some extra side income.

- Not having the same people fixing bugs as the ones making it could be a bad practice. Learning from your mistake is a bliss. This would create a bad pattern of someone saying "our expert analyst will catch/fix it anyway"

- 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.

If I don’t have to invest significantly in you to learn our code base I would be very happy to pay you as a freelancer to help us figure out bugs.

Your personality is also one that I would fight to get on our team.

You can sell support and warranty contracts.

Usually it will be for software you helped to develop originally, or the one you know well (commercial or open-source).

I do this when customer asking for long-term support. Some companies are moving slowly, so it will take time to them to discover bugs.

You just adding XX% to the contract, the added benefit that you will have an incentive to reduce the amount of bugs/defects in your code.

Several times it was like free money, other times it was several days of work fixing bugs. I think worst case it was a week of work.

OP here:

Thank you for the radical candor everyone (I greatly appreciate it)!

While I'm humbled by the warnings, I'm also inspired by the encouragement.

Consulting, quality assurance, and security bounties are all related to my passion, but as I've clarified in other comments: investigating and fixing known bugs is the niche I'd like to aim for, regardless of the non-technical challenges in procuring such work.

For one thing: if you’re going to make a post like this, put your contact info in your profile!

It is very possible to do this if you are a contractor working on a tech stack that people consider “legacy” because the software built on this will more likely be in a maintenance/bug fix phase (as a broad generalisation).

Pure bug fixing can be like being paid to solve coding puzzles. But of course often bugs are at the intersection of non technical factors other folks here have mentioned.

Sometimes you have to open up and investigate can of worms nobody who is around knows about. That would involve you in various stacks of software with very weird quirks and unintuitive design decisions. That sounds like hell to me and am wondering how you’d be able to handle these without investing tons of time in learning the domain and the SW involved. I’d be interested in learning from your experience as well.

Of course you can. I'm freelance and code-review & tricky-bug-fixing is practically all I do. And I'm quite good at it. Clients devs are usually stuck in fixed ways of thinking so it makes sense to bring in an outsider to dig into the code in ways they couldn't have predicted.

The trick is this: after reviewing enough code, you develop an intuition to where bugs are hiding.

I can very much relate to how you feel about the flow of fixing bugs. Have you considered finding bugs? There's already a thriving freelance ecosystem around that. Hacker one / bug crowd etc. Once you report them you may be able to suggest ways for companies to fix the bugs and possibly get hired as a contractor to that end.

There was a company doing something like this for ios apps.

The approach was to charge a monthly fee to maintain a company’s apps.

Anytime there was a reported bug or the app needed updating. It was resolved.

This company had a number of clients. And gave their clients peace of mind.

One can start this by soliciting companies with apps.

The customers that I would see this working for are sunset projects that need less than a full time dev and 90% of the work is bug fixing.

Specializing in languages where there is very little new development, and large legacy code bases would be a good place to start.

Have you tried pentesting/security?

A lot of the time it seems like it's about finding bugs, maybe not directly fixing them, but at least find what needs to be fixed

Reach out to me if you’d be interested in a contract or job (email in bio)

Would definitely be interested in hiring you for my startup. email in bio

Of course you can. That said, there is a higher goal. You should work towards building software services that contain fewer bugs and are more reliable than the market based alternatives. Fixing other peoples stuff severely limits your potential IMHO.

I call this being a Software Mechanic.