Could this be the future of debugging?
BugUFO is a marketplace where programmers can post code bugs with a bounty, and the first programmer to solve the bug gets the bounty.
The founders of BugUFO are 2 programmers, Ilya and Youssef, who were frustrated with the current state of debugging.
According to the founders of BugUFO, typically, for a programmer to debug a program, they initially try to solve the problem themselves using print statements, and shotgun debugging. If they’re slightly more advanced or the problem is slightly more difficult, they might use a debugger and approaches such as program slicing, code profiling, time travel debugging, why-because analysis, and delta debugging.
When all else fails, most programmers tend to resort to googling the error in the hopes of finding some solution to their problem.
This is fine for simple bugs, but for slightly more niche or nuanced bugs, googling is not always a fruitful path.
Nicolas: The first question that I feel will be on most people’s minds is how this differs from free question answering sites (Stack Overflow, Quora, Reddit, etc.) or doing a quick google search?
Youssef: We like and are frequent users ourselves of all these options. But oftentimes, we’ve posted questions that were ignored either because they were too long, had been marked as duplicates and closed (in Stack Overflow’s case), have gotten no useful responses, not to mention the anxiety and uncertainty of waiting for a response.
In addition, if you’re googling, each response you come across needs to be vetted to make sure it solves your problem and not merely a similar problem.
If you ask a question, and get a response, the response may be correct but too advanced for you to understand.
With more complex problems, the response can sometimes be in the form of a hint, pseudo-code, or a code-snippet, instead of working code.
Essentially, you’re unable to immediately incorporate it into your own code.
There’s a cycle you go through of checking whether or not every answer actually solves your problem by making a change in your code, running it, and seeing if the error is gone, and the code functions as expected.
There are only so many cycles that a developer can go through before they burn out.
We’re trying to remove this menial, cyclic checking process such that you get rapid, tested solutions instead of suggestions that may or may not work.
Another pain point in terms of question answering sites is on the problem-solver side, helpers are operating without enough information. For instance, users posting the problem to question answering sites may not elaborate on their specific development environment, or don’t post all of their code, only a small segment, or their question suffers from the XY problem.
Nicolas: What about paid options (Fiverr, Upwork, etc.)?
Ilya: The paid options are more for wholesale outsourcing of code or feature development instead of quick code fixes.
What if you’re trying to learn coding yourself or are a developer who has a bug in your code? Do you really want to go through the time and energy of vetting five developers, coordinating timezones, and overpaying, only to have 1 bug fixed? That could’ve been done in 15 minutes or you could’ve gone and done something else while someone was working on your problem without ever vetting any candidates. Basically, we’re saying: At the click of a button, someone starts working on your problem without ever having to talk to a human. If your problem isn’t solved, you don’t pay anything.
Nicolas: Why is your solution a paid solution rather than free?
Ilya: Paying someone drastically increases the odds that someone will actually solve your custom problem and do so in the timeframe you desire.
We think that BugUFO could be like a wormhole through time for self-learners — Youssef, BugUFO
Nicolas: As a self-taught programmer, I’m curious how this affects learning. Is paying for debugging going to hurt or help the learning experience in your opinion?
Ilya: For someone who is serious about improving, seeing working code can help the learning experience (e.g. by giving them the freedom to play with the code) and encourage them to keep on going.
Youssef: For many people, struggling for hours to solve a problem you care about can hurt you more than help you because you end up developing negative associations with the project or with programming in general if you aren’t making progress. We think that BugUFO could be like a wormhole through time for self-learners, allowing for accelerated just-in-time learning.
Nicolas: How does a coder decide when to use BugUFO vs. figuring it out themselves?
Ilya: There are probably three typical use cases:
If you come across an error that feels way beyond your current skill level
If you feel that you could eventually figure it out but it might take several days or weeks, and you’d rather make faster progress.
If there’s a time constraint that is tighter than your expected turnaround time solving it yourself.
Nicolas: Thanks for your time. Would you be open to maybe doing a follow-up interview in the future?
Nicolas: By the way, how did you come up with the name “BugUFO”?
Youssef & Ilya: Top secret. (Laughter).
(Special thanks to J.B. for getting me in touch with BugUFO’s founders.)