5 Tips on getting pull requests approved
Quick disclaimer, this article assumes good intentions. If you are looking to get malicious code approved, go somewhere else.
- Keep it short
- Know your audience
- Add a visual
- Be respectful
- Give a little, get a little
Intro - pull requests?
The unfortunate reality now adays, is most companies require every commit of code to be approved by another developer. Now, that sounds nice and noble, keep it accountable, but in reality, it has been a major pain in the butt. On occasion a typo or mistake is caught, but in my experience more times that not it just starts petty arguments and can cause resentment.
Tip number 1. Keep it short
This one is pretty obvious, but large pull requests are less likely to get approved than small ones. Unless you have a habit of getting large pull requests approved, start small.
Tip number 2. Know your audience
Not all developers are equal, some know more than others, don't assume a negative comment on your PR comes from a place of omnipotence. Sometimes, developers are in a hurry, and just put down the first thing that comes to mind. A simple polite negation can work wonders.
Tip number 3. Be humble
If the your comment gets rejected because of a typo, don't get upset. Correct the typo, try again. A spelling error isn't something to get bent out of shape, just thank them for observing where you made a mistake, and correct it.
Tip number 4. Be respectful
For example, let's say you add a simple PR, that adds the following CSS.
flex-direction: column; display: flex;
And let's say your PR receives a comment.
It doesn't work like that.
Now, your gut instincts here might be, what the heck does that mean? And might be to ask him to explain himself, wrong, don't do that. If the comment says it doesn't work like that, a screenshot showing it works as intended should be sufficient. Sometime's developers give lazy responses, and at some point you will too. Be respectful.
Tip number 5. Give a little, get a little
Hey, if you aren't getting any code approved, ask your yourself, are you approving anyone else? PR's are work, do some PR's for someone else and they might do the same.
The unfortunate reality now adays, is most companies require every commit of code to be approved by another developer.
I quite like it, it helps catch some problems and keep a homogeneous style. And sometimes you learn some interesting new ways to do things, although mostly in the beginning.
It's also my understanding that research supports that it is one of the most effective ways to improve quality, although that's from blogs, I didn't read original research articles.
They're good tips though to get the most out of them though.
I'd add: use good tooling. Preferably really do review pull requests, so that the review can check out the code, should they so choose. I've experienced pre-commit reviews and it's just less convenient (not to mention easier to forget and harder to check).
I like all 5 tips. They are helpful and pragmatic. Still, there is quite a negative connotation for code reviews. And, in my experience code reviews can be super beneficial to ensure high-quality code and to learn and mentor others. Also, very beneficial for knowledge dissemination. Here one example from Code reviews at Microsoft: michaelagreiler.com/code-reviews-at-microso..
But, the benefits of code reviews really depend on the culture and if companies/project follow best practices and not just use code reviews as a way of "window dressing". If done correctly, they add a lot of value.
"The unfortunate reality now adays, is most companies require every commit of code to be approved by another developer. Now, that sounds nice and noble, keep it accountable, but in reality, it has been a major pain in the butt. On occasion a typo or mistake is caught, but in my experience more times that not it just starts petty arguments and can cause resentment." (from the post)
It seems you have made some bad experiences with code reviews. Unfortunately, that happens, and sometimes code reviews are used as a tool for power plays, or to belittle other devs. That's not how it should be. Still, when that happens, code reviews aren't the problem. The underlying culture and team dynamics are the actual problems. And code reviews just bring that to the surface and make it visible. So, I actually think they can be helpful to spot such problems and act accordingly.