One code review changed my career as a software engineer. It was around three months into my first job. On that day, I was working on a different part of the codebase that I had never touched before. Up to that point, I had worked almost entirely in JavaScript, but that part of the codebase was written in Python. It isn’t the language I am most comfortable with, but I had some experience using it for school work and my side projects. I implemented what was required, created a new PR, and asked one of the senior engineers to review it. He was a machine learning engineer with many more years of experience than me, and we had never worked on the same part of the codebase together. What he does was way beyond my understanding. I remember I was proud of the fact that I implemented something using a different language. At the same time, I was nervous about getting my code reviewed by him.
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.
If you’re interested in code reviews, becoming a better developer, and/or helping other people become better developers, check out Antcode here. I'm trying to create a community where everyone has access to code reviews.
If you liked this post, we recommend you subscribe to the Antcode blog and follow us on Twitter at @o_nagen and @mkinoshita12 .
If you want to get reviews on your code and learn from reviews on other people's code, we recommend that you check out what we're building at Antcode and join our code review Slack group.
Happy coding!
Top comments (16)
I really liked this article. In the company I'm currently working at, code reviews are not a true practice, It has only 3 people responsible for reviewing and we are a team of 25 developers. Sadly they refuse to comment and truly analize the code of others, it is really a pity. Since I saw this kinda of issue I'm trying to show them how everyone can improve their skills if we take code review seriously. It's been a hard battle but I'll try to win this.
It is great to hear that this article was somewhat helpful to you. I truly believe code reviews are great ways to improve as a team as well as individuals. Each developer learns new things every day. If you can have a system to share the knowledge with a team, your entire team will benefit greatly. I know it is a time-consuming activity, and some people don't like it, but you got this! Good luck!
Hi Monique! I'm curious, why do you think your company avoids quality code review? Do you have any sort of process in place?
Thanks for sharing, I was writing a similar post and your post inspired me to finish it.
About this:
'...I no longer just wanted to ship functional code. I wanted to write code that is readable and maintainable. Software engineering is teamwork.'
I agree with you. In fact, I believe that this is what differentiates seniors from mid/juniors devs. The multiple aspects of this topic are really interesting. Good reminder there.
That's wonderful to hear. Please share your article with me once you finish it. I'm excited to read it!
Very relatable article! Personally I would like to join a software company of a substantial size is because of the opportunity to learn from more experienced developers and understand better software development practices.
If you have the time, try to contribute to open source projects. Pick ones from big corps with known high quality standards (Google, Facebook, Square). This is definitely how I learned the most: gtk+, libxml, GWT, Dagger, etc.
Reading code reviews from those projects can be a good first step too (I'd encourage reading all issue and PR comments as they happen in select projects)
Yes I am planning to do so😄. However, I do have this irrational fear that high quality standard repos are too big/complex for me to understand enough without guidance.
Anyway, I do currently have a project that I intend to get on soon, making baby steps towards a better self...
The best projects to pick are the ones you leverage in your projects. And even if you don't understand the code sometimes, reading the review comments is still valuable (chances are you'll also learn about how the code works 😉)
Hi Thomas,
Would you mind elaborating on how you tackle a fresh open source project? I am quite clueless as to where to begin when faced with the repo. Is the process of getting to understand what is going on by simply...reading every single line of code or every single issues from start to finish? Is there a strategy that you employ when starting out with a fresh project?
In most cases, I had started with an issue I had with the project, trying to find my way in the code and understand how things are supposed to work. So starting from an error message I got, or an output file I thought should be generated by was missing, an option that I thought would match my use case but didn't work the way I thought it would, etc.
git grepis one of my best friends in those cases (for a statically-typed language, grepping the type's name to navigate to its declaration or use sites; for JS or Python grepping the import paths).Or if you wonder how one feature works under the hood, go explore that part.
For issues and PRs, look for "good first issues" you could possibly pick up at fixing, and read select PRs that pique your curiosity.
Then watch the project to get notified of every new issue/PR and comment.
That's how I generally do it (I learn by reading, not necessarily practicing), but YMMV 🤷
I know how you feel really well. I think it is a dilemma many developers have :/ Some people love to work in a small team or even alone, but there is currently no great way for them to learn from experienced developers. I hope this to change in the future tho!
You may not be able to learn from experienced developers directly if you are working alone, but there are plenty of indirect ways to learn from great developers:
I'm not saying this is the easy or preferred way of becoming an experienced developer but it can be done--this is how I leveled up.
Finally, just keep practicing. Review your own code a few days after you wrote it. Our go look at something you wrote 6 months ago and see if you can find a way to improve it.
I 100% agree! Code reviews can be a frustrating experience if we all don't have the right attitudes. It is a fairly common practice in the software industry, but people don't get taught how to do code reviews properly. That could be one of the reasons code reviews are not done correctly in some companies too. Thank you for your comment!
I can't see the code for context but it sounds to me that the reviewer is a bit pedantic, the comment: "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." for example is fine, but this really doesn't matter 99% of the time, sometimes it enchances readability to pass the boolean flag to avoid context switching between just slight variants of a function when reading. Hearing the comments were longer than the code is not normally a great sign, at this stage I'd recommend a face to face conversation or a phonecall.
I like the part on the catch 22 part of getting code review is at work to learn to improve on their craft. I love the part to help circumvent the problem was participating in open source projects.