[jrochkind1]

There are always bugs.

What keeps bugs from happening is processes, not programmer conscientiousness. Processes begin with a test suite, and enough time spent on maintaining the test suite. And generally, enough time spent on managing bugs.

The way for the software to have fewer bugs is for the organization to spend more resources on processes to reduce bugs. If they are choosing not to do that, perhaps thinking they won't gain/lose enough business over it to justify the investment... well, your boss has already told you that they think the number of bugs you have is appropriate for business requirements and there is no reason to invest in having fewer. So, you can accept that, and give up your feeling of responsibility to make things different (your boss has already said they don't want things to be different), or you can look for a different job, I guess!

I admire you for feeling guilty for putting out crap software, and don't want to tell you you are wrong. Too many of us get paid to put out crap software. I think we are responsible for making people's lives just a bit crappier having to deal with our crappy software. I don't want to tell you to become a soulless automaton who doesn't mind producing crap that makes people's lives crappier as long as you are getting paid.

(Alternatively, maybe it's not crap software? Even high quality software sometimes has bugs. Maybe you are being overly critical? But there is so much crap software out there, that's not what I'd assume).

But it sounds like there isn't a lot you can do about it at this job.

Or... is there? We can brainstorm. It's not spending your time doing things your boss has told you you should not spend time on, though, to try to save the company from itself. That won't be good for your career, or your personal stress level, and also won't help. Whatever it is will about trying to pitch your boss/team on new processes.

[ironmagma]

> What keeps bugs from happening is processes, not programmer conscientiousness

While maybe it's not sustainable, or maybe it doesn't work for large companies, if you're at a startup or small company, conscientiousness absolutely plays a large role. That's not to say that process cannot help reduce the mental burden of developing though by reducing the need to be conscientious.

[jrochkind1]

I mean, sure, you can try to write good code or not give a shit, and if you do one or the other will certainly matter to the outcome, agreed.

But I (who has worked my entire decade+ career on very small teams/companies/projects) think that, past a certain point of not being just apathetic/irresponsible, "trying harder not to have bugs when I write the code the first time" has much much less effect on outcome than code review (including even code review by yourself, but giving yourself the time to do that, including some resting time in between when you write and review your own code), test suite, QA, error monitoring (with allowance to spend time diagnosing and fixing any errors reported; actually just having that allowance in general, otherwise bugs keep building on bugs), etc.

Plus if you think bugs are a result of "not trying hard enough" or "not focusing hard enough", you just stress yourself out. Even more so on a small (or especially solo) team. There are ways to create high-quality low-bug software without stressing yourself out. I don't think they include a model where bugs are your fault for not trying hard enough.

But sure, everyone should try to write good code, and if you don't care about what you are doing and don't even try, you will have more bugs, it's true.