Pull requests, I love to hate you

Whether they are called pull requests or merge requests, they are like this thing you need to do but don’t really want to (like calling your grandmother).

Reading a pull request can be painful (“I have no fu*** clue what this code is about, am I supposed to be able to do the same thing?”) and it can be devastating when receiving tons of feedback on your code (“Am I really that dumb and bad at coding?”). Here is your guide to be a good PR reader, and also become a better developer.

Become a good PR reader

Rule #1: ask questions

The first and main goal of pull requests is to learn. Learn new tricks, remind yourself with best practices, discover parts of the code you never saw before or don’t deal with that often… All of this serves one goal: become a better developer. Once you reach that level of “I know what I am reading is not the best way to do it and I can suggest improvement”, this feels great. But to reach that level, you need to read code. A lot of code. And if you don’t ask any question, there is a good chance you are missing out on important knowledge.

Rule #2: be a best-practices keeper

If you don’t deal with best practices not being followed in a PR, you never will. This is now or never. So yes, you feel bad about commenting again about that variable not being named in camel-case, but these are the rules, everyone needs to follow them. And if you don’t have a clear set of rules and best practices, maybe it is time to create that list.

Rule #3: be mindful of the context

The same feature can be developed in a dozen ways. You have the quick and dirty (it is a nogo unless it was approved this way!), you have the “I am such a god, my code cannot be better than this” and you have the “clean and working code, I am outta here”. Depending on your seniority, your knowledge of this part of the app, the time you had… you might have chosen a path your colleagues do not know about. So when reading a pull request and seeing an ugly shortcut being taken, be mindful and assume the best from people.

Rule #4: you won’t be able to say you did not know

Sharing a PR with the rest of the team is a way to share responsibility for the implementation chosen. You can’t discuss every detail beforehand, so most of the time, the pull request is the first (and last) chance to discuss the solution.

Become a better developer

Rule #1: stop hiding things in the closet

There is a good chance you have processes in place where your PR needs to be read before it gets merged (if not, you should). If that is the case, do not hide things under the carpet. Either you fix the code you know is dirty, or at least you add a comment in the PR explaining the whys and asking for advice.

Rule #2: proof-read yourself

Before submitting your PR, proof-read yourself! The probability is pretty high for you to have missed a semi-colon, left a console.log or some commented out code. Clean up and then submit your PR.

Rule #3: do not feel overwhelmed by the feedback

If your PR gets a ton of feedback it can be either three things:

• you did not follow the guidelines and best practices. You can’t really complain.
• your colleagues did not understand the context (very little time, workaround approved by team leader…). You need to set the record straight.
• you are just not the best (yet) and your code, even if it works, can be improved. Embrace the feedback!

Rule #4: pushing your code is only the beginning

You thought that coding this cool feature was your greatest achievement for the day and you were done with this story? Well, bad call, a story is both a working feature and a clean code. Walking through the PR gates is half the journey. Hang in there! And remember: you might be asked to dive into the same code in 6 months, and because you wrote it in the first place, everyone will assume it will be easy for you. So don’t shoot yourself in the foot, and clean up :)

Rule #5: accept the help

A pull request is also a way to ask for help from other team members on how to become a better developer. You don’t know everything, so accept the help and embrace the feedback.

Imagine a world where developers from the same team do not proof-read each other. Imagine stumbling upon a very dirty code, months after it was written, with no one around to explain it, and with fear in your stomach that you will break something if you touch it. Imagine a world where your app has so little conventions and best practices that nothing is done the same way, and any improvement costs10 times what it should. Welcome to a world without pull requests! I don’t want to live in this world.

Instead, come work at Whoz, your first PR will be hard, but you’ll become the developer you always dreamt of becoming!