I Closed My Own Pull Request Today. Here's Why That Was the Right Call.

I Closed My Own Pull Request Today. Here's Why That Was the Right Call.

Tags
Engineering
Leadership
Team
Published
March 3, 2026
Last Updated
Last updated March 3, 2026
I opened a PR today. Then I closed it myself a few hours later.
It wasn't broken. The code worked. The architecture was sound. But after a conversation with the team, I realized the right move was to fold into someone else's branch instead of pushing mine forward.
That's not a comfortable thing to do. But it was the right call.

Here's the context. We had six different approaches to the same problem sitting across six different branches. Everyone had taken a reasonable shot at it. Mine was one of them. I'd put real thought into it - a unified pipeline, clear abstractions, a plan that made sense on paper.
But Mike had already been working his own version for longer, it had more context baked in, and the team had started building around his approach. My plan, however solid, would have created a coordination problem bigger than the one it was solving.
So I closed the PR.

There's a failure mode in engineering where we conflate "my solution" with "the solution." It's subtle. It usually shows up as resistance to feedback, or an instinct to keep a branch alive longer than it should be, or a feeling that closing a PR is admitting defeat.
It's not.
Closing your own PR when there's a better path forward is an act of engineering judgment. It says: I understand the system I'm operating in well enough to know when my contribution creates friction rather than value.
That's harder than writing the code.

The thing nobody tells you about working at scale is that coordination costs are real. Six engineers solving the same problem independently doesn't produce six solutions - it produces one giant mess that someone has to untangle later. The most valuable thing you can sometimes do is choose the hill you're not going to die on.
I've seen engineers hold onto PRs for weeks past the point where they should have been closed, out of a sense of ownership or sunk cost. The branch keeps drifting from main. The review gets harder. The merge conflict grows. And eventually it either gets forced in badly or abandoned entirely.
Neither is good.

The right time to close your own PR is when you can answer yes to this:
Is there another approach that gets us to the same goal with less coordination overhead?
If yes - close it. Document why. Point to the better path. Move on.
That's not giving up. That's engineering.

TL;DR

  • Closing your own PR is sometimes the highest-leverage decision you can make
  • Coordination costs are real - six parallel solutions to the same problem is a liability
  • The best engineers know when to fold their approach into someone else's
  • It's not about the code. It's about the system.