Very real, also within corporations in proprietary code.
One thing helps a lot: you don't owe "them" anything, also when working on proprietary code inside corporations. Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report.
(If you haven't shuffled through hundreds of poorly formulated issues you may not realize just how much effort that is).
Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report.
Presumably this is what product management is supposed to function and give attention to, isn’t it-at least to an extent? Or have I misunderstood what those staffers do?
Seems lately I’ve seen developers frustrated about this because they want to be developers, but the company wants them to be everything and anything more (sometimes, maybe often-times because of poor resource allocation/chronic understaffing on the part of the business) from triaging feature builds to project managing entire releases.
> Very real, also within corporations in proprietary code.
Yeah, I've fielded quite a few internal bug reports that amount to "it doesn't work". My stock response is becoming "what is the symptom you're actually experiencing when you say 'it doesn't work'?"; that usually gets more information.
(The internal ones are perhaps worse, as you are beholden to respond to them, since it's from a coworker.)
More broadly: always set boundaries for yourself. You may not have a choice to ignore the bug in a corporate setting, but you need to be willing to kick issues back to the originator for lack of information and /or lack of willingness on their part to help isolate a way to reproduce the problem.
One thing helps a lot: you don't owe "them" anything, also when working on proprietary code inside corporations. Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report.
(If you haven't shuffled through hundreds of poorly formulated issues you may not realize just how much effort that is).