I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time.

One leader kind of listened. Sort of. I'm pretty sure I was lucky.

That's what I hear.

I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for.

I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)

I worked at various small agile startups around SF. Retired last year.

They weren't big enough to have "official policies". We talked to each other instead.

I did work a few years at big companies twice. That taught me to appreciate the simple life :)

I'm not going to share my employer, but this is exactly how we operate. Bugs first, they show up on the Jira board at the top of the list. If managers would abuse that (they don't), we'd just convert them to stories, lol.

I do agree that it's rare, this is my first workplace where they actually work like that.

Frontend bugs mostly stem from usage of overblown frontend frameworks, that try to abstract from the basics of the web too much. When relying on browser defaults and web standards, proper semantic HTML and sane CSS usage, the scope of things that can go wrong is limited.

>For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

I've seen that very argument several times, it was even in the requirements on one occasion. In each instance it was incorrect, there were times when a second page was reached.

IMHO the best way to deal with that situation is to mark the bug as wontfix. Better to have a policy of always fixing bugs but be more flexible on what counts as a bug (and making sure the list of them is very small and being actively worked on).

I don't think, except for a direct regression, it's even possible to define a bug in a way that isn't the same as a feature request. They're identical: someone wants the software to do X, it doesn't do X, maybe we should make it do X. (Except, again, for it used to do X but now doesn't and that wasn't intentional.)

Treating bugs as different than features and automatically pushing them to the front of the line likely leads to a non-parsimonious expenditure of effort and sets up some nasty fights with other parts of the company which will definitely figure out that something being a "bug" gets it prioritized. Obviously this can be done poorly, and why even have engineers if you aren't listening to their prioritization as well.

Top commenter's "AFAYK" acronym is covering that.

The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs.

https://github.com/kelseyhightower/nocode

We kinda always leave documentation and test bugs in. Documentation teams have different scheduling, and tests are nice TODO's.

There are also always bugs detected after shipping (usually in beta), which need to be accounted for.

>I'd love to see an actual bug-free codebase.

cat /dev/null .

As opposed to the current 100% defects approach they seem to have adopted.

In my world, improving the UI to save clicks is a new feature, not a bug fix.

Assuming it works as intended.