Remix.run Logo
Uehreka 13 hours ago

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

In my experience there are two types of low-priority bugs (high-priority bugs just have to be fixed immediately no matter how easy or hard they are).

1. The kind where I facepalm and go “yup, I know exactly what that is”, though sometimes it’s too low of a priority to do it right now, and it ends up sitting on the backlog forever. This is the kind of bug the author wants to sweep for, they can often be wiped out in big batches by temporarily making bug-hunting the priority every once in a while.

2. The kind where I go “Hmm, that’s weird, that really shouldn’t happen.” These can be easy and turn into a facepalm after an hour of searching, or they can turn out to be brain-broiling heisenbugs that eat up tons of time, and it’s difficult to figure out which. If you wipe out a ton of category 1 bugs then trying to sift through this category for easy wins can be a good use of time.

And yeah, sometimes a category 1 bug turns out to be category 2, but that’s pretty unusual. This is definitely an area where the perfect is the enemy of the good, and I find this mental model to be pretty good.

tonyedgecombe 9 hours ago | parent [-]

>high-priority bugs just have to be fixed immediately no matter how easy or hard they are

The fact that something is high priority doesn't make it less work.

ChrisMarshallNY 6 hours ago | parent [-]

Or more.

I often find the nastiest bugs are the quickest fixes.

I have a "zero-crash" policy. Crashes are never acceptable.

It's easy to enforce, because crashes are usually easy to find and fix.

$> ThreadingProblems has entered the chat