I’ve made a conscious effort to stop apologizing for bugs in my code

This reads a bit like one of those feel-good "managers should be good to employees! agree?" posts on linkedin. The bugs I see in PRs from even some mature people are things like input_array[0] without checking the array for null or size. Anyone beyond cs101 can tell you this is unacceptable and careless, and the author likely had a "fuck it" attitude, and was in a hurry to get back to Netflix or whatever was really on their mind.

Should we expect for them to go into a full-on dogeza Japanese kneeling bow apology? Of course not. But there are many cases where a person glaringly half-assed something, cut corners, quietly committed something directly to master. And yes, this person should feel some kind of regret, or should be brought to stop such behavior because it is extremely destructive and is totally avoidable and caused not by overworking or accident but by persistent carelessness and neglect, so it cannot just be cheerfully swept under the rug.

This is the same thing I was thinking. We write imperfect software because the market (and the law) does not incentivize the significant extra work required for perfect software. Blaming individual engineers or organizations for that doesn't make any sense.

To commenters who compare work of programmer with the work of civil engineer:

There is an explanation to this discrepancy. Risk = probability of fault * cost of fault. Programmers usually work with the data. Data has a pretty very unique property that it is easily and cheaply copied and restored. It also means data can be replicated more easily, which allows to build systems with large amount of redundancy. Therefore, price of a software bug is usually orders of magnitude less than the price of breaking something in the physical world. This allows to drive up probability of fault parameter and allows for much faster evolution and less regulation.

The biggest career lesson that I've had is that 80% of development is testing.

Should you apologize for bugs? No. But if you're doing professional quality work, (as opposed to prototyping or researching,) a large portion of your time (as a developer) should be writing automated tests (like unit tests) to test the code you write.

Bugs are the responsibility of the process that brought them there. In most cases it is shared responsibility.

Why doesn't your dentist mess up 1 out of 5 interventions? They have gone through years of strict training and there are giant liabilities in place.

In development? A lot of self-taught developers, who can always jump to a next gig because of never-ending demand. This sets up the scene for a totally different scenario - never-ending stream of bugs.

If you want your team to have less bugs, then as a manager make sure you have a process in place that optimizes for that. Start with your hiring process and add requirements for code quality practices. Then build a process that includes strict commit guidelines, documentation, code reviews and QA process. Most importantly, add time to estimates that ensures all of the above is checked properly. After all that is in place, define in a clear way some sort of liability for bugs.

Your dentist goes through all of that, why not your developers doing arguably equally important work?