As a junior engineer, stepping into the world of code reviews can be both exciting and nerve-wracking. It’s a crucial aspect of software development that ensures the quality, readability, and maintainability of code. Approaching them with the right mindset and following some key principles can help you grow as a developer and make the most of this learning opportunity. In this article, we’ll explore the dos and don’ts of code reviews for all software engineers.
Do: Understand the Project, Don’t: Make Blind Changes
Reviewing code without understanding the project context can lead to making incorrect assumptions about the code’s purpose and functionality. This can result in misguided comments and unnecessary rework. Ineffective code reviews can waste both your time and the time of your colleagues. You might spend hours reviewing code that doesn’t require changes or raising issues that are already addressed in the project’s design. It’s why I believe that understanding the project is the first step in giving good feedback.
But there’s more: be sure to ask your colleagues about setting up your Integrated Development Environment (IDE) to use the team’s auto-linting configuration. This practice is becoming quite common. Once configured, coding standards and conventions are applied automatically every time you save a file. Don’t hesitate to ask your colleagues questions to clarify any doubts. Adhering to these standards ensures consistency in the codebase and makes it easier for the team to maintain and understand the code.
Do: Test Thoroughly, Don’t: Rely Solely on Reviewers
When I first started participating in code reviews, I often fell into the trap of relying too heavily on my colleagues to catch all the issues in my code. I would submit my work, confident that they would point out any bugs or problems. But this was not only unfair to my peers but also harmful to my own personal growth. While it’s great to have other people look at your code, you shouldn’t depend on them to find all the mistakes. Also, the main job of the people reviewing your code is to make sure it follows good rules and fits well with the rest of the project. They might not notice every little mistake. By testing your code thoroughly before getting it reviewed, you make sure it works well, and you look more responsible to your team. It’s like being a reliable team player and helps you gain a good reputation as a junior engineer.
Do: Embrace Feedback, Don’t: Take it Personally
One of the most valuable lessons I learned was the importance of embracing feedback. At first, receiving comments on my code felt like a personal critique. But I soon understood that it wasn’t about me; it was about improving the code. I learned to carefully consider the feedback I received. Understanding that my colleagues had different perspectives and experiences helped me see the bigger picture. I realized that in a collaborative environment, feedback is essential for creating quality software, and it’s directed at the code, not me. I started treating feedback as an opportunity to improve rather than a criticism of my abilities. If I didn’t understand a comment or disagreed with it, I’d engage in a respectful discussion with the reviewer to bridge gaps in understanding. This approach not only improved my code but also strengthened my relationships with my team.
Do: Be Patient with Approvals; Don’t: Rush to Approve PRs
In my time as a junior engineer, I’ve been in situations where I had to review code from more experienced teammates, including my team lead. It can be tempting to quickly say, “Looks good!” and approve their work. But here’s the thing: that’s not always the best way to go. I’ve learned that it’s totally fine to slow down, take a good look at the code, and ask questions when something isn’t clear. Sometimes, I have to double-check or ask about parts of the code. About half of my comments in code reviews end up being questions, and this is not just about seeking answers; it also highlights that the code might not be as clear as the author intended it to be.
By questioning the code, you’re not just seeking clarity but also subtly indicating that the code may need some improvements. It’s important to understand that even excellent engineers can benefit from feedback and iterate over their code to make it even better. I’ve realized that I’m not just there to agree with everything. I’m there to make sure the code is top-notch and follows the right rules. The big lesson from my experience is this: taking your time, asking questions, and not rushing to approve code in reviews is really helpful for your own learning and making the code better. So, don’t let the pressure to say “yes” quickly stop you from growing and making the code great.
In conclusion, code reviews are a valuable opportunity for junior engineers to learn, grow, and contribute to the development process. Embrace feedback, maintain a positive attitude, and always seek ways to improve your coding skills. By following these dos and don’ts, you can navigate code reviews effectively and become a more skilled and collaborative member of your development team. Remember, the goal is not just to produce better code but to become a better developer in the process.
