How do you handle a loss of confidence in your own ability?

I'm really sorry this happened to you and it has to be so difficult for you like this. Can you tell us anything about what happened? I've seen some things happen like this where some was out for vacation, forgot to reset the password on a critical build system, and a whole org couldn't ship product for a week while they were out. I think set backs like this are difficult, but it would help you to understand what gaps in knowledge you have and break through those brick walls hard. I did that in my career multiple times and I never regret learning too much as it made me such a better engineer and teammate. Right now, it's up to you to prove to everyone it won't happen again, but I would go overboard and really lay it on thick so they truly realize and see that commitment. Might be a bit overboard, but it certainly can't hurt.

Sorry to hear you're in this rut.

Is your lack of confidence impacting your ability to perform? As in, you're too afraid to make code changes right now?

Either way, if you need external validation, I suggest talking to your EM. Go into it prepared. I suggest doing a brief post-mortem of what went wrong and how you've taken steps to safeguard it from happening again. This will show a reasonable manager that you're taking responsibility and action for your mistakes.

The next time they bring it up or 'hang it over your head', I would ask them if they are confident in the system now. And if not, how can you improve upon that.

With the confidence issue, it could help to work on some smaller tickets to build your confidence back up and look back on the work you've accomplished. Talking to a trusted peer could help as well. I keep a log of kudos that I look through when I feel down.

But the best path forward is to move on. This won't be the last mistake you make. The best you can do is to minimize risk moving forward and avoiding the same mistakes.

If you want to dig deeper, I feel you are experiencing shame over your mistake and you're trying to avoid that shame again. That's a natural response. But maybe there's some internal work that needs to be done there.

Hoping you feel better, good luck!

@Xue Ha That is such a great response. We'll always make mistakes but it is important to treat this as a learning process and move on. Lots of different variables will come into play to make unique situations and we always want to act in healthiest manner possible. I've also been in situations where I was forced to make a decision on mine own since I wasn't getting and would never get the face time needed to help resolve the issue because of how peers were spending their time. It really stinks, but I'm glad to not be around those folks anymore and that I can focus on problems that are just more interesting overall.

Sorry to hear that you're feeling like this: Every engineer has been there.

Fun fact: A few weeks after I started at Meta, I broke a logging endpoint during bootcamp. Around 50 million events were dropped before I fixed it. 😅

What was nice about that instance and Meta as a whole is something absolutely crucial to any healthy engineering organization: Blameless culture. I wasn't scolded at all for breaking that endpoint - The owner of the endpoint just told me to be more careful next time and gave me some resources around how I can better ensure the quality of my code later on. My bootcamp mentor even smiled and laughed when I told him about it.

The core idea here is that when it comes to mistakes, the focus should always be on how to improve.

In your case, it seems like the blameless aspect is missing to some extent, but you can still apply the growth mentality. The best way to get out of this rut both mentally and with your manager is to show a laser-focus on learning from your mistakes and improving the overall engineering landscape because of them. Here's how you can do it:

1. Create a post-mortem doc, either one each for each instance or one big doc that covers all 3 and tries to draw themes between them. This doc should outline what broke, how many people it broke for, how it was broken, and most importantly, initial suggestions on how to prevent this from happening again.
2. From the doc(s), solicit feedback from your teammates async at the very least. Given that this is for a mission-critical system, you should hold a team meeting for this as well.
3. Extract action items from the feedback garnered in Step #2. Make sure that every action item has a well-defined task with a due date and priority. Here are some ideas around action items:
   1. Adding more automated tests
   2. Create a mechanism to more slowly roll out changes to production (dogfooding -> alpha -> beta -> 5% A/B test -> launch)
   3. Increasing the amount of analytics and alerting surrounding the service, so you can catch issues earlier before the blast radius gets too large
   4. Refactoring the service, so it's harder for human error to break prod. Ideally, a production-breaking change won't even compile/build
4. Actually execute on the action items and be public about it - At the end of the day, you build up your reputation by getting stuff done. I saw action items from SEVs slip all the time at Meta: I hope you can be better than we were. 😂

It's totally okay to feel bad about breaking stuff: What separates the great engineers is that they're able to convert that negative feeling into motivation to keep getting better. It's clear to me that you care a lot - I'm sure you have the skills to come out of this a better engineer than you were before. 😊

Here's some other resources around blameless culture and learning from mistakes:

• "How to ensure mistakes do not repeat?"
• "How to turn a string of silly mistakes into a mature positive outcome?"