[perrygeo]

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.

[cannam]

> Unless you're promising them a long-term commitment (and at that point are you really freelancing?) they might be hesitant to invest

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.

[perrygeo]

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

[arthurcolle]

This is a cool story, thanks for sharing. What is your background if you don't mind my asking?

[amerkhalid]

One way to do this would be to become expert in one or two technologies or frameworks such as Kubernetes or Laravel. Then it should be fairly quick to become productive in a new codebase.

[majormajor]

I somewhat feel the opposite about context - I'm not sure there's a better way to get context rapidly than to try to fix bugs. It's a targeted investigation into existing functionality, which helps a lot compared to many other sorts of tasks.

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.

[Ma8ee]

In my experience most tricky bugs aren't isolated, but caused by module A assuming something about module B that isn't true, which makes module C behave strangely.