[HN Gopher] Ask HN: Can one be self-employed fixing bugs?
___________________________________________________________________
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?
Author : 0xf005ba11
Score : 137 points
Date : 2022-10-29 11:33 UTC (11 hours ago)
| motoxpro wrote:
| Would definitely be interested in hiring you for my startup.
| email in bio
| JamesBarney wrote:
| 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.
| bombcar wrote:
| 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.
| surfmike wrote:
| Reach out to me if you'd be interested in a contract or job
| (email in bio)
| Ken_At_EM wrote:
| 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.
| Syzygies wrote:
| 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.
| watmough wrote:
| 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.
| josh_fyi wrote:
| 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.
| rmnclmnt wrote:
| 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.
| sokoloff wrote:
| 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.)
| gtirloni wrote:
| 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.
| al2o3cr wrote:
| 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.
| ranger_danger wrote:
| if it were so easy, why do they exist in the first place?
| didgetmaster wrote:
| >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.
| nonasktell wrote:
| 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
| harel wrote:
| 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.
| sixdimensional wrote:
| 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.
| ekidd wrote:
| > 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.
| bsima wrote:
| 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.
| poisonborz wrote:
| - 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.
| jf93ap29sh wrote:
| Fixing bugs (even super hard ones) is a very narrow set of
| expectations for someone in software.
|
| Sounds cliche 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.
| pdimitar wrote:
| It is not possible to be only good at fixing bugs. I believe OP
| is referring to a _preference_ , not a single area of
| expertise.
|
| 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.
| [deleted]
| perrygeo wrote:
| 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.
| majormajor wrote:
| 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 wrote:
| 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.
| amerkhalid wrote:
| 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.
| cannam wrote:
| > 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.
| fallat wrote:
| 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 :)
| bjornlouser wrote:
| You barely get credit for fixing bugs as a full-time developer
| within most organizations so the role of part-time bug
| specialist, although appealing to me as well, is a bit of a
| stretch.
| [deleted]
| pdimitar wrote:
| Yeah that's my experience from a long career as well. People
| never appreciate what can't be seen. And if we make it more
| visible we get lambasted for "writing bugs", sigh.
| kyriakos wrote:
| This is great advice. May as well try get hired in a
| contracting agency so they can allocate you to their clients
| and keep you with a steady stream of work. Most developers hate
| fixing bugs and would love to drop them on contractors.
| Smeevy wrote:
| 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.
| slewis wrote:
| For one thing: if you're going to make a post like this, put your
| contact info in your profile!
| BurningFrog wrote:
| 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".
| ryukoposting wrote:
| An old IRC friend of mine was a consultant who described his
| job as "coming in and de-spaghettifying old codebases." Have
| you looked for consulting jobs?
| tcmb wrote:
| 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.
| codingdave wrote:
| From a product management perspective, all bugs take 2 hours.
| Or 4. Or 8. But you just pick a number and roll with it.
| Because if you are looking at how bugs will impact a roadmap,
| then you can take them in aggregate and not give a hoot about
| one specific bug. Most bugs will be quick, and they will
| balance out with that one nasty one that takes a week. You do
| need to leave space in the project for bugs... so experiment a
| bit to find out how much space any specific team needs, and
| just know that much time will be spent on non-feature work.
| JamesBarney wrote:
| This is a terrible deal. A good rule of thumb is the person who
| understands/controls the risk best should take it on. And your
| team who understands the code base best and has fixed these
| types of bugs before would know far better how long they should
| take than a new contractor.
|
| I don't think there is any industry where work like this
| wouldn't be time and materials.
| dinom wrote:
| 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.
| canyon_throwawy wrote:
| 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.
| kyriakos wrote:
| Codecanyon quality is ridiculous. Mostly its wordpress stuff
| and generally its premium theming/plugin ecosystem is
| unfortunately hot garbage bought by developer-less agencies to
| use on clients once off.
| O__________O wrote:
| 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.
| blablabla123 wrote:
| 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
| h-c-c wrote:
| 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.
| tartoran wrote:
| 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.
| djmips wrote:
| I call this being a Software Mechanic.
| gbro3n wrote:
| 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.
| mfashby wrote:
| Unsure about self employed, but there are definitely
| consultancies who specialise in legacy software maintenance
| https://www.legacycode.rocks/
| eaplant wrote:
| 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.
| mypastself wrote:
| Another issue is that I prefer being a Dementor on my own...
| tayo42 wrote:
| how did you do that there? ive been actually trying out this
| site and all i get are kids asking for help with their homework
| nivertech wrote:
| 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.
| pabs3 wrote:
| The FOSSjobs folks have a bounties section on their wiki that
| might he useful:
|
| https://github.com/fossjobs/fossjobs/wiki/resources#bounties
| pyrolistical wrote:
| 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.
| tayo42 wrote:
| Is there some where to get good advice about getting stated
| with something like this?
| pyrolistical wrote:
| I found this channel to be a good introduction
| https://www.youtube.com/c/LiveOverflow
___________________________________________________________________
(page generated 2022-10-29 23:01 UTC)