Do these 4 things before sending a PR!!!!

Do you want to produce production ready code? If yes, follow these 4 tips.

Image by lukasbieri

Sending a pull request, or “PR” for short, shouldn’t be taken lightly. When you send a PR, you’re communicating to your lead dev that your code is primed for production. Since customers will interact with production code, it’s important that you establish good habits before sending a PR. In this article, I will discuss four such habits.

Remove any logging methods

Before sending a PR, I try to delete any console.log or debugging statements. In the very beginning of my career I didn’t practice this habit and sent a PR riddled with debug statements. My senior devs were quite gracious and taught me a valuable lesson during a code review. I learned that code sent in a PR should be safe and reliable. And there’s nothing safe or reliable about sending code infested with logging statements that could lead to malicious activity.

Check for missed UX experiences

When implementing a new feature, It’s very easy to leave the customer out of your solution. What do I mean? Pretend you are given a task in Jira that stated you should create delete functionality to a list of “to do’s”. After reviewing your Jira ticket, you successfully implement code that allows a user to delete a “to do”. Let’s also pretend when the user deletes a “to do”, they make a request to a server to update the database. This request takes time so the U.I on the front end will update your todo list in less than a second.

My concocted scenario seems reasonable. However, there’s no mention of a loading indicator to notify the user that something is happening in the background. They just hit the delete button and notice a change in a short amount of time. In other words, it works without the user knowing.

As a junior developer, you might be tempted to think that a working solution is a complete solution. This form of thinking is incorrect. As you progress in your career, you should consider your first solution as the beginning of something greater. And in this case, adding an activity indicator would be greater.

Consider your variable names

If you’re like me, when you first implement a solution, you just want the dang thing to work. And sometimes this means you create variable names that aren’t the most robust. Take these javascript variable names for example:

const user const data const obj

The examples above may fit your use case. However, it may also be a good idea to check if there’s room for refactoring. This may seem trivial but good code should be understood by more than the person that coded it. 

Let’s say the variable named “user” is actually holding the user’s id. It would be more descriptive to label it as such. Either using camel casing or snake casing:

const userId const user_id

The same principle can apply to the variables data and obj. If the data variable contains grades fora student, you may need to rename your variable so it reflects its purpose:

const studentGrades const student_grades

Take a break

I’ve found that taking a reasonable break before a PR can refresh your brain and allow you to see things that a fatigued mind would ignore. Remember, coding is a mental sport that requires work and rest. I recently had a PR comment on something very silly (I mistyped a url in a Next.js project). I also remember I was battling brain fog before sending that particular PR. Let this be a lesson for you. A tired mind is a mind more prone to make mistakes.