
Ask HN: How much time does your employer allow you to spend on solving one bug? - id122015
Because I&#x27;ve never been employed as a programmer, I dont understand how employers measure programmers worth.
======
greenyoda
_" How much time does your employer allow you to spend on solving one bug?"_

It's hard to answer that question because bugs exhibit so much variation
across many variables:

\- Some bugs take minutes to fix (e.g., an obvious typo or omission in the
code) but others may take weeks to fix (e.g., the programmer misunderstood the
requirements and has to rework a large part of the code to fix erroneous
assumptions; or a bug occurs intermittently under conditions that nobody has
yet figured out how to reliably reproduce).

\- Some kinds of code may be harder to debug, e.g., a web app is usually
easier to debug than a device driver, since there's more visibility into what
the code is doing.

\- Some bugs are of critical importance to key customers (and thus justify a
big time investment), but some are in obscure parts of the product that nobody
uses (and may not be worth fixing at all).

\- Some bugs make it impossible to use an important feature (justifying a big
time investment), but others can be easily worked around.

\- Some languages have constructs that make code harder to debug. E.g., there
are lots of bugs that arise from memory management in C (using stale pointers
to heap memory, etc.) that can never occur in higher-level languages.

\- It's much easier to fix bugs in code that you wrote than in code written by
someone else (who may have left the company and is not available to answer
questions).

------
cauterized
Depends on the bug.

A major performance and cache corruption bug in production had four people (on
a 6 person team) each spending probably 12 hours per week on it for two
months.

A complex corner case that gets hit twice per week out of 100 million requests
has been ignored for two years.

A bug that only affected bad actors (people hitting a spam detection
threshold, even in good faith, were getting 500 errors instead of a warning)
waited a week even though it was just an obvious one-line fix.

The thing about bugs is that you often don't know what's causing them, and
some are too complex or require too-specific conditions to be able to track
down. If you don't know what's causing it, there's no way to know how
difficult it will be to fix.

So most bugs get - if not timeboxed - heavy follow up and pressure to fix it
or drop it or work around it after a couple days of non-progress. But there
are some bugs you just have to keep working on until you squash them, no
matter how long that takes.

