After about 30 minutes passed, I went to the bathroom and saw him starting to read my PR. This was good; he would finish the code review by lunchtime. I could merge the PR by early afternoon and could go home feeling good about myself. He didn’t finish the code review by lunchtime. By the time he finished it, it was already past 2 pm. He spent hours reviewing my code. I was somewhat confused and opened the PR. The comments were longer than my code. It made me frustrated and disheartened.
However, as I read the comments I realized that all of what he pointed out made total sense. His comments were thoughtful and never insulting. Some of them were stylistic comments, but what fascinated me were the comments about design principles or code smells. For example, he commented “If you have to pass a boolean as a flag, it is usually a code smell. It means that the function could be two separate functions.” I never paid attention to it until that moment, but it made so much sense. If he didn’t point it out, I would have kept writing the code the same way. All I needed was for him to point it out just once.
But that code review taught me something far more important than specific style tips. My attitude toward writing code had changed from that moment. I became more critical about my code. I started reading some books to learn software design principles. I even started reading reviews of other people’s PRs. After that code review, I began to understand what it means to be a software engineer. I no longer just wanted to ship functional code. I wanted to write code that is readable and maintainable. Software engineering is teamwork.
It’s been more than 6 months since I quit my first job to start a company with my friend. I have been coding as much as before, maybe even more than before. However, I’m noticing the difficulties of growing as an engineer without code reviews from more experienced engineers. Learning a new language is especially challenging. It is hard to know the best practices.
The main purpose of code reviews is to keep the quality of a codebase high, but it is also a great way to share knowledge among a team. Junior developers can learn a lot from code reviews. If you want to get code reviews outside of the work context, a popular way is to participate in open source projects. Open source is a great way to learn from other engineers, but it can be time-consuming and intimidating. Another issue is that some people like to build something on their own rather than participating in open source projects. They don’t have a chance to get their code reviewed.
I’ve seen engineers get rejected at interviews for lacking experience in a production environment. They don’t know how to contribute to a codebase in the context of a company. These people are stuck in a paradox. How can you expect a recent grad or self-taught developer to understand software engineering fundamentals if they have no prior work experience and the only place you can get the feedback on your code is at work?
I believe code reviews are too valuable to be accessible only to select groups of people. Everyone should be able to benefit from them. Even just one code review can unlock a whole new level of coding ability for someone like it did for me. This is why we started Antcode, to make code reviews accessible to everyone.
If you’re interested in code reviews, becoming a better developer, and/or helping other people become better developers, check out Antcode here. I’d love to hear what you think, so don’t hesitate to leave a comment or shoot me a note at: firstname.lastname@example.org.