Most people agree that if you want to build a successful business, first you have to build a few failed ones. Same thing applies to code: bad code is a require

Most people agree that if you want to build a successful business, first you have to build a few failed ones. Same thing applies to code: bad code is a required step before good code. Accepting this fact is very liberating. Quality of my code is not the measure of me as an engineer. It's how I distribute quality that's important. I have a very similar experience to author's. There's plenty of bad code I wrote that never got used in the end. And while it's sad it did not get used, at least I didn't waste time perfecting it. There's plenty of bad code I wrote that is being used for years and most engineers don't even know that it's bad. Their eyes will bleed if they look at it. But they have no reason to: it just works. There's plenty of bad code I wrote that caused pain. So I just made it better when it did. I anticipated the pain and I was ready for it. Unfortunately most of our practices and tooling are structured around pain avoidance and reduction. But no amount of unit tests will deliver the same value to you as, let's say, Sentry.