And it isn’t just your _appearance_ or _pay_ you should be worrying about. If you fix a nitpicky bug that affected 5% of the users — congrats that’s a pretty big bug! But could you have built a new feature that would roll out to 50% of users in that same time? In many situations, building the new feature will have a bigger impact on the world than the bug fix. Obviously will depend on the exact circumstance. But you should consider the opportunity cost.
Hmm. Well, of course it isn’t on any one person to fix a systemic issue. But, I really would not want to use a system where the institutional decision was made to focus on new features instead of fixing bugs that hit 5% of users.
The problem is that the real impact and the perceived value of each path are not necessarily the same.
Building new things is sexy and highly visible. It's easy to say about yourself "I built that cool new feature" or better, to promote "I might build something of incredible value". You're front-and-center with decision makers, shaping the future.
Conversely, debugging is perceived as a cost center. "I fixed that critical infrastructure that used to work with only minor interruption" or "Maybe everything will break and you'll need me to fix it" are not nearly as exciting. Worse, the best maintenance is completely invisible, fixing problems before they are felt. You're in the background, dealing with the legacy of the past.
If your organization is like that then let them know. Suggest some leading indicators that they could track so you can take credit for your preventative work. If all else fails, then you can decide if you want to just do visible work or leave.
