I was working night support, learning backend on the job. The role required both (frontend and backend) and I needed to move fast.
One night, I was fixing a feature. Tested it. Looked good. Pushed it to production.
Then I broke something else entirely. A feature users relied on stopped working. For hours. That's the mistake everyone fears. The one that makes you question if you belong in this industry.
But here's the counterintuitive part: that mistake made my team trust me more.
What Actually Happened
I was supporting a CMS for Canadian car dealerships. Technical team in Iran, clients in Canada. Someone had to work nights to provide real-time support during their business hours.
I'd been doing frontend for a couple months when they moved me into full-stack night support. I needed to learn backend fast.
One night, a client reported an issue. I dove into the code, found what looked like the problem, made the fix, tested the specific feature. It worked. Pushed it to production.
Within an hour, messages started coming in. A different feature was broken. Users couldn't access a critical part of the system. I'd fixed one thing and broken another. I only tested the feature I was fixing, not the features that depended on the code I changed.
The bug stayed live for hours while I frantically debugged, found the issue, and rolled out the fix.
The Moment of Truth
When something like this happens, you have two choices.
Option 1: Minimize it. "It was only down for a few hours." "The codebase didn't have proper documentation." "I was under pressure to ship fast."
All true. None of it matters.
Option 2: Own it completely. "I pushed a bug to production. I didn't test thoroughly enough. This was my mistake, and I'm making sure it never happens again."
I chose option 2.
I messaged the team immediately. Explained what happened, what I'd done wrong, and what I was doing to fix it. No excuses. No deflection. Just the facts and the plan.
Then I made changes to my process. Started testing not just the feature I was working on, but adjacent features that touched the same code. Added more comprehensive checks before pushing to production. Documented the areas of the codebase I learned so the next person wouldn't make the same mistake.
What Changed After
My team didn't lose trust. They gained it.
Because they saw I wasn't going to hide problems or make excuses. They knew that if I made a mistake, they'd hear about it immediately from me, not from angry clients hours later.
That transparency made me more valuable. When you own your mistakes, people know they can rely on you in the moments that matter.
Over the next year, I handled that position better than any developer they'd had before. Not because I stopped making mistakes completely, I didn't. But because when I did make them, I surfaced them fast, fixed them fast, and learned from them.
By the time I left that role, they offered me 4x my starting salary. Not despite the mistakes I'd made, but partly because of how I'd handled them.
Why Owning Mistakes Builds Trust
When you screw up, your instinct is to hide it. Minimize it. Blame the codebase, the timeline, the lack of documentation.
But here's what people actually need to hear: "I made a mistake. Here's what I'm doing to fix it. Here's how I'll make sure it doesn't happen again."
Owning your mistake shows you're not going to gaslight them when things go wrong. You're not going to make excuses or disappear when problems arise. You're going to face it, fix it, and learn from it.
Most people deflect. So when you don't, you stand out.
How I Handle Mistakes Now
I still make mistakes. Everyone does. But my process changed after that night.
First, I test more comprehensively. Not just the feature I'm working on, but the features that connect to it. If I change authentication logic, I test every flow that touches authentication.
Second, I communicate immediately when something breaks. Not after I've tried to fix it quietly. Immediately. "This is broken, I'm investigating, here's what I know so far."
Third, I document what went wrong and why. Not just for me, but for the team. So the next person doesn't make the same mistake.
Fourth, I build in safety nets. Staging environments that mirror production. Automated tests for critical flows. Code reviews before merging. Not because I don't trust myself, but because I know mistakes happen and systems should catch them.
These practices don't prevent all mistakes. But they reduce them, catch them earlier, and make the impact smaller when they do happen.
Final Take
The bug I pushed to production could have ended my career in that role. Instead, it strengthened it. Not because the bug didn't matter. Because I owned it completely, fixed it fast, and made sure it wouldn't happen again.
Mistakes happen. Own them. Learn from them. Build systems to prevent them. Move forward. Your reputation isn't built on being perfect. It's built on being honest, accountable, and reliable when things go wrong.
That's what clients remember. That's what teams value. That's what turns a junior developer into someone people trust with their most important projects.
Next up: “My Actual AI Workflow" Subscribe to get it in your inbox next week.