Search for a command to run...
Advice for productive code reviews and becoming a more confident developer
Software engineer based in Pittsburgh, PA with interests in cloud computing, cybersecurity, and professional growth.
Some other things I like: history, exercise, rock climbing, coffee shops, live music, reading, podcasts
Thanks for sharing.
I have also shared my thoughts as a code reviewer here [1]. If you wanna check it out.
[1] https://anasanjaria.hashnode.dev/lessons-i-learned-as-a-code-reviewer
Great post, Kyle!
I remember joining a company as an intermediate developer where everyone else was at Senior level.
When I would be doing code reviews, my first action was to run it and check whether the functionality works and try to break it.
This inspired the whole team put flags on PRs on whether it should be at least run and checked because I was catching a lot of bugs that would show up in running it.
I think anyone can do good code reviews as long as they are diligent about it and in an open enough environment where they can ask why something is done in a specific way.
PRs are a great way to learn the codebase and how everyone else writes code.
How and why you should be tracking your projects, career goals, and accomplishments
How tech bootcamps and certifications can replace a degree, give you bang for your buck, and provide upward mobility in your career
In this tutorial, we’ll be walking through the steps to create a basic web application that takes user input and makes a request to a serverless backend consisting of an API Gateway, a Lambda function, and a DynamoDB table. By the end of this tutoria...
Imagine starting to read from a random page in the middle of a random book. You’d probably like to go back to get some context and understanding of how the story got to where it is. You’d also probably like to know what the book is about to anticipate the chapters ahead. Now also imagine everyone else around you already knows everything about the book. This intimidating situation is what being a junior developer is like. There’s a lot of pressure to get up to speed and so much to learn -- while mid and senior-level developers seem like they know everything.
As a junior developer it's very common to feel nervous, insecure, or feel imposter syndrome at a new job. There’s a lot to deal with at once – meeting new coworkers, learning new tools/technologies/processes, understanding the context of a project, and understanding a team’s roadmap and mission. One of the most daunting aspects of a junior developer position is actually diving into the code.
At first glance, success in the coding aspect of the job may seem like a foregone conclusion – someone entering their first developer position probably has a degree, certifications, or ample coding experience. But, the reality is that each university, coding bootcamp, self-taught developer, and business has their own standards and expectations when it comes to code. Luckily, code reviews are the perfect place to learn a team’s processes, follow the example of senior devs, reach for a deep understanding of the code base, and build confidence as a junior dev. Once a junior developer feels more confident in their code and reviewing others’, “imposter syndrome” begins to become a thing of the past.
Code reviews can make a junior dev feel timid, frustrated, or downright scared. Anyone who has had 20+ commits and 50+ comments or suggestions on a pull request knows these feelings well. However, there are many tools and resources to make this important aspect of a developer role easier.
As the developer, the goal is more than just getting something up for review. When submitting code for review, the goal is clearly to accomplish the task laid out in a ticket, but also have the pull request be clear, concise, and easily reviewable. A developer who is assigned to review this code may be approaching it without any context, so it is important to have commit messages and descriptions that facilitate easy understanding, in a reasonable amount of words. Also, the pull request should not be too large; reviewing large pull requests takes up the valuable time of other developers, along with time used for any back-and-forth discussion. If a pull request starts to grow unreasonably large it can be broken up into smaller, digestible PRs. This allows reviewers to quickly get feedback to the developer without needing to spend hours on a single complicated PR.
A useful tactic for junior developers in code reviews is to comment on their own pull requests. Along with a clear and concise title and description, comments can point reviewers to areas that need more attention (or scrutiny). This, in turn, can reduce the amount of time from pull request to merging or even reduce the number of bugs that slip through. Good developers can admit when they’re not sure of a solution and are open to new ideas and suggestions. If there is an area of code that is complicated, hacky, or the developer is just looking for alternatives, then they can comment and explain their engineering decision or ask for suggestions. Here’s an example of this:
It’s obviously also important for a developer to thoroughly review their own code. Although a developer might say “I wrote the code, so I know it best”, it is very likely there will be mistakes, things forgotten, and opportunities for improvement. Self reviewing code in the same way you’d review someone else’s code can help cut down on the “noise” in pull requests. Here is an example checklist that gives an idea of the things that should be done when putting code up for review. Not every point will be relevant depending on the team/code, but it’s a good place to start:
Source: https://github.com/kjthorpe18/pr-checklist/blob/main/pr-checklist.md
As a code reviewer, many of the same rules apply! The above checklist can be used to review someone else’s code. Junior developers are often afraid to nitpick more senior developers’ code, but enforcing clean code and standard practices shouldn’t be something to be timid about – this is a way to improve the whole team.
Another important aspect of reviewing code is simply asking questions. Far too often, a developer will see code they don’t quite understand… and simply give it an approval. This is an easy way for bugs to slip through the cracks, possibly resulting in time, cost, and business consequences. A good developer will point to code, admit they aren’t fully grasping it, and ask clarifying questions.
This is also good for the developer who wrote the code; they should be able to explain what the code does, and this rubberducking could even shake out bugs and improvements. It also leaves a nice record on the pull request for any future developers in the same boat, looking for clarification!
Finally, a reviewing dev should take their time reviewing code, but not too long. A reviewer has the responsibility to get to these reviews in a reasonable amount of time to reduce how long the developer has to wait for feedback. As mentioned before, large pull requests should be broken up into easily digestible chunks, but sometimes, big PRs happen.
There is a pretty good chance that an organization has some documentation about their coding best practices. It may be worth it for a junior dev to ask during onboarding if there are any resources like this. Style guides, process docs and checklists, and setup guides can be extremely helpful when starting out; new developers can’t be expected to get everything right the first time, so referring to a “source of truth” is often the best path. These documents can often be on internal wikis, a team’s Slack or Teams channel, or within READMEs of individual code repositories.
Unfortunately, a lot of times there are unspoken (or untyped) rules between developers and teams. This often comes from a team working together for a while and becoming more comfortable with each other’s expectations. Someone outside of the team wouldn’t know these rules or preferences, and so a new junior dev wouldn’t have this tribal knowledge. But, it’s still important to document these rules. If an organization doesn’t have any documentation like this, it could be an opportunity for a new developer to familiarize themselves with their codebase and create these helpful documents. A project like this is a perfect way to start strong in a new position. Unfortunately, these documents are often neglected – teams need to remember to update them every so often in order for them to remain useful! A good way to remember this is to have an agenda/action item for team meetings or to set a recurring reminder to assess relevant documentation.
Although there are many aspects of starting a new position as a junior developer that are difficult, code reviews can truly be the worst. Luckily, there are ways to turn those negative feelings into a confidence in reviews and a drive to learn. Code reviews are meant to be beneficial to the developer, the reviewer(s), and the rest of the team. Using tactics like following a checklist when creating PRs, commenting on one’s own code, asking questions about confusing areas, and creating/following established standards can vastly reduce imposter syndrome and increase confidence in a junior developer.