Have you ever reviewed other developers' code? Have you ever received a code review from another developer (outside your company)?
In this blog post, I will be sharing with you what it takes to do code reviews, what is the process and what you can learn from it.
As a Solution Engineer, part of my job is to review customers' implementation. I find this part of my job very exciting and challenging because it exposes me to different use cases and technologies on a daily basis.
Why Offering Code reviews?
- Implementation Review: implementation review is important because you have the opportunity to check that the customer is using your product (APIs, SDKs) in the most effective way. You can run sanity checks on the code, best practices review and debug known issues. The more detailed the code review is, the better would be the final result, both for the customer and for your company. For the customer, because he would have an improved product. For your company, because a better implementation can lead to more utilisation which means more revenues.
- Build Trust: doing code reviews and providing feedback is a fundamental part of building trust with customers. Customers trust your feedback and they will implement your suggestions to improve their solution. Moreover, they will share with you any future expansion plan to ask you which is the best way to achieve it.
Table of Content:
Do Your Homework
The process for a code review starts before having the code from the customer. You, as the reviewer, need to ask a few questions to the customer. That's why I always suggest making a preparation call before the actual code review. You have to go through the following questions:
- Use Case: understanding the use case will help you to dive deeper into the code. You will have a clearer understanding of how they have structured the code modules and why.
- Pain Points: asking which are their pain points is a good indicator of where to focus during the code review. If they told you that they are receiving always a specific error or that their customers complain about a specific process, you would focus on a specific section. Plus, you can also investigate internally (with Support and Engineering Team) if their issues sound something familiar to them and if they are related to a specific version of your product.
- Technology Used: if you are reviewing client-side code, you have good odds that they are using something between ReactJS, Angular or Vue.js. Even though you don't need to be a top expert in the framework, knowing the basics helps. Luckily, the three frameworks share some of the concepts so it should not be a big deal having basic knowledge on all of them. For the server-side code, that's not always the case. If you are not an expert on the code language you have to review, you can always ask internally for support.
Use Your Secret Advantages
So you gathered the information from the customer, the next step is to confirm it with your internal tools. Meaning?
Customer point of view on issues could be slightly different from what you will see on your internal logs. You will have to weight the two inputs and come up with your idea. You can leverage your company's internal tools such as logs, support tickets and internal dashboard to realise what could be the root cause of the issues and where to investigate.
Using the internal logs, you can draw a dashboard with the most common errors grouped by APIKey. From that, you will get an idea of which module of your customer's implementation could raise those errors. Remember that you can leverage the results of this dashboard with the customer and discuss what should be improved and, most importantly, if they are receiving the same feedback from their customers.
Checking the most recent support tickets opened by your customer helps you understand which are their recent complaints and how they were solved (if solved). Even discussing with your colleague from support can give you some clues on what to expect from the code review.
The Actual Code Review
Great, you completed the prep work for the code review. It's time to get it started. It's time for the exciting part.
Don't focus too much on code style, it's not part of your job to judge how companies have different code style convention. Try to identify where your company APIs are used (or where the SDKs methods are imported and used). Then, for each of the functions check the following:
- Input Parameters: the input parameters provided to the function make sense for their use case? Could they be changed? If so, provide examples.
- Error Handling: if the function fails, how does the code handle the error? Do they display a clear message to the end-user?
- Retry Logic: if the function fails, do they have retry logic in place? Do they have a maximum retry value or timeout?
Remember the most common error that you analysed in the previous section? Perfect. Now it's time to try to find the pattern in the code that could lead to those errors. How? Well, there is not a mathematic formula. You would need a blend of intuition, knowledge of your product, experience and critical eye. Don't worry too much if in the first code reviews you have a hard time finding those patterns. The more you do, the easier. ✌️
Always collect your findings in a summary document that you will provide to the customer after the code review is completed. I will write another blog post on how this document should be structured (stay tuned) 😊
Time to Discuss
The last step of a code review is to discuss it with your customer. Make sure you include the relevant people on the discussion such as the developers and the tech lead. Since the call will be deeply technical (code level discussion), business people shouldn't be needed. A good practice is to always ask them if they would like to join or not but make sure to set the right expectation on the technical level of the call. Being clear on this will make the call as productive as possible.
The time has come. You feel a little bit nervous because you have to tell other developers (that you have never met) your feedback on their code. I know, it's fine to feel like that (especially the first times) but try to look it from a different angle.
You are going to discuss their code to help them improve their product and meet their goals. The discussion has to be constructive, you are not blaming them for the issues on the code. Based on your findings, you are there to guide them on better decisions and best practice they could implement. They will trust you because you are the subject matter expert in that particular field. Never say "this implementation is wrong", better to say "this implementation could have been done in a different way. Let me explain... what do you think?"
In this phase, what pays the most is to give your honest opinion. If you have found issues on the code, tell them and show them how they can improve it. It's an open discussion between you and them. You may find that their implementation makes sense because you were not aware of some product requirements. Or maybe not, and they will thank you for the feedback.
I always had a great experience giving an honest and respectful opinion to other developers. Setting the discussion in a friendly mood helps a lot to build trust and get honest and productive answers from them. And then, you will know that you did a great job when they will send you an email to recognize your help and tell you that they have implemented the changes to production and received great feedback from their customer. That's the best part of the job 😀
Conclusion
I wrote this blog post to share how I do code reviews and how my process improved with my experience. Only last year I did something like 50+ code reviews.
The only real boss you have is the customer, so keep in mind that being honest and open to discussion always pay in the long run.
If you liked this article, follow me on Twitter for more 🤓
Icons from :
- Icons made by Prosymbols
- Icons made by phatplus
- Icons made by Flat Icons