Think of PRs as requests for your code to be improved, not merged.
Here’s a reframing exercise to prime yourself for receiving feedback and learning when sharing code with others. When expanding the PR acronym in your mind, don’t use “Pull Request” but “Please Refine.”
Think of PRs not as requests to pull your changes but as opportunities for others to help you improve your code.
Here’s my work. Help me make it better.
Practice and feedback are the only way to level up your coding skills. Whether it’s a more experienced engineer who can show you a better approach, a peer that can spot a typo, or someone earlier in their career than you not yet cursed with knowledge, asking others for help is a sure way to refine your work and in turn your skills.
“PR as please refine” is a mindset worth promoting at the organizational level.
As a thought experiment, imagine if every PR that got merged was the improved version of what was initially suggested.
One obvious, practical consequence is that it would take longer for each PR to land.
But what would be the impact on the code’s quality? How much learning could authors and reviewers make together, then bring into their next project?
I speculate that those long-term, less quantifiable benefits would significantly make up for the slower merge pace.
Pull requests are already an essential part of many teams’ development processes. Reframing them to “please refine” will also reinforce a culture of constructive criticism and continuous improvement.