The beauty in a pull request

No matter if they are called pull requests or merge requests, code review, they are a review to help your code quality, and I love them.

Learnings & knowledge sharing

I love to learn new things, and a good pull request is just another source to gain more knowledge about new ways of doing something, new language features, structures, encapsulations, and many more.

By forcing colleagues to work together on a feature branch, you gain the benefit of discussing the solutions choosen, the practices and patterns used, but also that the involved people will review each others code, and thereby learn new things to improve their own code quality. This can be both reviewer and the person making the code.

Qualities of a good pull request

When making a pull request try to think about the reciever of your code. This means that you keep a high standard both in the delivered code, but also make a good review that is easy to work on.

Often your reviewer might not know all the details of your code, what it is meant to do, what behavior it will have over time or from different conditions. So make it easy for your reviewer to not having to look up descriptions on the story, gettting attatched files or images, finding links for the layout/UX. Provide the necessary information to help your reviewer, make a good description to explain what you are solving, and the way you are solving it.

If your solution does things, that might not be obvius to the eye, provide descriptions or images to showcase them. This could be how it behaves before data is loaded, showing things different when a certain situation happens, error messages, information boxes appear.

These are visual markers helping to understand the product you have produced, but also have in mind how you make your commit messages. If your reviewer is going through your commits as a timeline to tell how your worked, these can be very useful and give a lot of information of what you do. So be informative and describtive in your commit messages, to provide as much information as possible.

Structure your commits so related things are committed together - for instance 3 files working on the same change should be in one commit. Structural changes should if possible be seperated from formatting changes - especially if you have formatting tools like Prettier - so you can separate one commit with 4 structural line changes, from 100 formatting line changes. Try also to think about your commit history, your messages descibing what you are doing. This will make it easier for your reviewer to understand what actual functional changes you made, and not having to manually compare the content.

Keep it precise

A good quality of a good pull request is being precise. Precise can also mean that you keep your branch only to what is needed to solve the story, bug, or spike. By limiting your code to only what is needed, will mean less code to look at and focus on, which again means it will be easier to understand the impact and implications of the code.

This can be challenging, and something I work on myself, but it is often possible to cut unnecessary code away, that could be put in a separate pull request. This would again make it easier for the reviewer to focus on only the scope of what the pull request is focusing on. So sometimes it would be better to break it up into smaller pull requests.

Another benefit of having small pull requests is that the code part you would end up releasing is contained in a smaller part. This means you could make a release version for each smaller code change, and if anything should be wrong when released, you can roll back a smaller part of the code, and keep as much functionality as possible in production.

Be your best self, NOT Gandalf

Remember to be your best self when you are the reviewer. A review can become a gate, that you are guarding, and the gate is the standards and quality to uphold. It can be easy to look down on others from your ivory tower of reviewership, but remember you are on the same team, trying to achieve the same thing.

Instead of being Gadalf the Grey, try to elevate and help them grow instead. If this was pair programming, you would discuss the best practice, architecture, algoritm and help each other to see opportunities for better code, not just what is wrong with the current one.

Remember it's important to have a good relationship with respect for and of your colleagues.

Improve the codebase, one pull request at a time