Comment by ryandrake

One of the toughest things I struggled with while transitioning from a larval junior developer to a senior tech lead to a project manager was the fact that (at least in the context of a for-profit business) not all bugs need to be fixed, even the ones you personally think are really really bad. The goal is to make money, not necessarily by producing the most perfect software. The quality bar needs to be high, but there is always a point beyond which the returns for fixing a bug are outweighed by the costs of fixing it: the direct engineering cost, the opportunity cost of not working on a feature, the cost of missing a deadline and not releasing in time for Christmas, the cost associated with the extra risk you’re taking by making a late change, etc. Good places judge all these costs, and the best ones have formal processes for judging lots of bugs at scale and constantly re-evaluate whether a bug should be fixed at this point in the project or not. Sometimes the clear right answer is “no.”