My PR Journey of Despair

There are so many times where I’ve submitted a PR knowing that it’s going to get knocked back.

I actually did a test six months or so to check if people were actually checking the code properly and deliberately wrote a PR with no unit tests. We need two approvals, and the first one went through fine. The second had a comment of the kind that feels personal. “Where’s the test for this?” they asked, like they’re uncovering a major scandal. Well, welcome to my world. At least I found out someone is doing a cursory check of the code, even if their tone sucked.

It’s the tone of the change request that’s a problem. Especially when we get bad advice from seniors and team leads who end up throwing us to the dogs.

The Bad Advice

There’s a special kind of bad advice that circulates in software teams, often masquerading as wisdom.

“Just open a PR and see what the team thinks!”

So one time I needed to implement a feature that used that shared module that nobody wants to touch. Each time we use it, we extend the functionality of it and it resembles Jenga as each developer carefully places a new block on top of the awful code.

I wanted to actually bite the bullet and rewrite that module. It’s not directly anything to do with the ticket I need to work on, but if I implement my changes everyone’s code would be better. The problem is we would all need to use the rewritten code, and over time migrate to this non-awful version.

Speaking to the team lead I got the advice as above. I’d overcome circular dependencies, the issues with the wider functionality and all sorts of hacks that had been used to get the code working in the first place. 

Of course, it didn’t entirely replace the functionality of the existing module. That’s fine as I’m not in the habit of changing other people’s code, and we could add back the complex functionality over time. The problem is I needed a buy in to get the initial version (that I needed implemented) into the codebase and go from there. 

The carnage began. Mostly mentioning it didn’t have some of the existing functionality (although we weren’t going to delete anything). That plus the questions around “why” and bizarrely pointing out the new solution didn’t use the old hacks. Oh, and could I add comments everywhere? The comments stacked up in their tens.

The coup de grace

A comment from my team lead suggesting that the entire approach might need to be reconsidered. “Perhaps we should think about a more holistic solution,” they write, despite the fact we worked on this solution together. They suggested I make the PR, and then stabbed me in the back as soon as it was created.

I just don’t understand why this might happen.

My Dream Approach

Unfortunately, I fell into a trap, set by a team lead. They wanted me to fail and they wanted to look technically good at my expense.

So, I will never fall into the “just open a PR” trap again, and will instead use a draft PR after a Pre-PR review.

Here’s the strategy.

Pre-PR Reviews

Pair program or ask for a quick informal review before opening the PR. It’s easier to handle critique in a conversation than a comments thread. Then, once the more powerful voices in the room are on side it will be much easier to get the PR moving.

Draft PR

Before diving into the full implementation, a draft can buy-in on your approach. It’s a lot harder for someone to criticize your architecture if they signed off on the plan, and there is no reason to get every test in order for the draft.

Conclusion

The next time someone says, “Just open a PR, bro,” know that you’re walking into a minefield. Take a step back, think strategically, and avoid becoming the latest casualty of bad advice. After all, collaboration should build teams up — not leave developers in despair over a sea of review comments.