The concept of failing is generally not something you should be proud of, but in fact in IT development this is something you should consider as positive. Let me explain why.
First let’s define what it means to fail. Failing in our case as nothing to do with creating bugs, failing is about detecting potential mistakes in advance and blocking the delivery process.
For example, you fail when you can not compile, you fail when your unit tests fail, you fail when your PR is not validated, you fail when your metrics are not compliant, you fail when your CI tells you it can not build, you fail when your CD can not deploy. All of this is a fail.
On the other hand, an incident in production, a lethal bug in your app, all those things are not failures, they are professional mistakes, they are everything that will destroy the trust people could have in your work. They are everything that will make your users use your app or quit it because its buggy and instable.
So please fail everyday and fail fast.
The faster you fail, the faster you fix and the lower is your risk to deliver bad things.
You should have multiple checkpoints where it is allowed to fail. For example, my “cycle of failure” is (ordered one):
So now you can tell your manager: Yesterday was a good day, I had loads of failures!
And when she/he will look unhappy just add: “Those failures were detected fast and everything is fixed so our risk has decreased!”