Chaos
We’ve all been there. Production’s down. Users are upset. You are getting pinged every 30 seconds. No one knows why this is happening.
Until someone runs
git blameAnd suddenly, a name appears. A line. A timestamp. A single moment in history ripped from its context and thrust into the spotlight.
And then, perhaps subconsciously, we blame the person too.
But here’s the truth. We’re often failing at three things.
1. Assuming Intent
We assume that the person who wrote this garbage code was careless, lazy, or short-sighted. We create reasons in our head on why this may be.
“They didn’t graduate from a top university”
“They didn’t work in FAANG”
“They never worked at a real startup”
“They’re self-taught. Of course, this is janky”
“They didn’t ask me for code review”
All of these do the same thing. They shift the focus from the problem and how to move past it to the person. These fabrications are self-serving. They make us feel better, smarter, more “senior”, at the expense of someone else.
But these are rarely if ever true.
If your goal is to engineer excellence, these stories are a distraction. They prevent root-cause thinking and poison collaboration within your team.
Worst of all, it forever disincentives and punishes engineers for taking risks.
Want to build a high-performing team? Assume good intent. Always. Question systems and processes, not people.
2. Forgetting Context
That “bad” line of code didn’t happen in a vacuum. Maybe product was breathing down their neck. Maybe tests were broken and they were flying blind. Maybe they just finished a 70 hour work week. Maybe they raised concerns that were dismissed.
Code is never just technical
When we rip a commit from its context and treat it as a standalone failure, we lose the story. And when we lose the story, we lose the opportunity to fix the real problem: broken processes (both technical and non-technical), unclear priorities, or culture debt that encourages short-term hacks.
Understanding context turns blame into insight. It shifts the conversation from “Who did this?” to “Why did this make sense at the time?“
3. Not Learning as a Team
Too often, incidents are resolved with personal postmortems.
“This engineer pushed bad code”
“They should’ve known better”
But this mindset misses the big picture. If a single engineer can silently push a bug that is worthy of a postmortem, that’s not their failure. It’s a systemic one.
Resilient teams treat every incident as a team-level learning opportunity
- Why didn’t we catch this earlier?
- Were our tests useful here or do we have gaps to address?
- Did we lack observability and only learn of this from angry users?
- Do our engineers feel empowered to push back on misaligned priorities?
Great teams build for failure, not perfection. They normalize mistakes and use them to uplevel everyone.
Some teams go a step further and celebrate failure.
Heck, a previous team I was on had a trophy that would rotate to the person who found a new way to break production.
It became a running joke. Sort of a badge of honor. But underneath the humor was a serious message:
“We’re not afraid of failure. We learn from it. We laugh at it. And we grow because of it.”
It’s not about assigning guilt. It’s about learning, building robustness, and growing. Together.
Git Forgive
So now, as a constant reminder of all of this, I have aliased
git blameto
git forgiveYou can do the same with this command:
git config --global alias.forgive blameSame functionality. Same insights. But a different posture.
A reminder that we’re in this together.
