Taro Logo
Profile picture

Code Review Q&A and Videos

About Code Review

Code review is one of the most common and powerful ways for software engineers to learn. On top of increasing code quality, it builds engineering culture within a team.

How to deal with a boss who is very nitpicky in code reviews?

Software Engineer at Early-stage startup profile pic
Software Engineer at Early-stage startup

My direct supervisor/ tech lead has a tendency to leave a lot of nitpick comments on my and my teammate's PRs during code reviews. I know the intention is positive, but in my view it's excessive and leads our team to spend too much time addressing stylistic or minor changes that don't materially improve the codebase. Since we're building for an early-stage startup I also believe it's a higher priority to ship code that works well enough so the business can get customer feedback, rather than focus on subjective stylistic things. It also increases the noise level in every PR and makes it hard to identify and focus on any comments about significant things.

I raised these concerns directly with my supervisor and also asked for clarification about which nitpicks are actually optional or if I can opt out of implementing any. My supervisor said I need to address/respond to every single nitpick comment, which means if I disagree or don't want to implement the nit, I would have to explain why every single time, which I think is not an efficient use of time. They also said we don't have to implement everything they suggest, and they welcome pushback, but I don't think they realize it feels a bit harder to do that when they leave so many nits and they are in a position of authority and are not my peer. I shared a suggestion that we make it ok for the PR owner to opt out of addressing a nitpick / leave it up to them to decide, and also try not to focus continually on stylistic things that can't be automated by linting etc. This was ignored though.

Does anyone have any advice on how to handle this situation? It's very frustrating and exhausting sometimes, and part of me has tended to cave in and just implement every bit unless I have a really strong opinion against it for the sake of avoiding spending time debating too much. I'd like to be wise about picking my battles.

Show more

What systems can I put in place so I make fewer dumb/obvious mistakes?

Entry-Level Software Engineer at Taro Community profile pic
Entry-Level Software Engineer at Taro Community

Basically, I feel like I have so many unnecessary ‘DUH! I can’t believe I missed that!’ moments in public -- mainly when asking for help and creating PR's.

For example, I recently was so focused on the more difficult part of a ticket, thinking about edge cases and trying to really polish this bit of functionality, that I spaced on reviewing the ticket before creating a PR. This meant the lead engineer reviewing my PR had to explain to me that I missed some other aspects of the ticket.

Another time, I spent a while trying to right a really good question about a solution to what I suspected was a tough issue. The problem? I hadn’t thought to test my hypothesis and confirm that this issue would occur (it didn’t) before formulating and asking my question. So I needn’t have bothered anyone else or myself about navigating this hypothetical problem.

When this happens, it makes me feel like my work isn’t thorough or to a high standard, not mention making me look bad. So it’s something I’d really like to improve, but it seems when I focus on being thorough it perpetuates the problem like in the two examples above.

I feel like I need some checklists/processes as guardrails for common scenarios (e.g., creating PR’s, asking for help) I can fall back on, because otherwise I feel my brain will keep missing things and making easily preventable mistakes.

Show more

How to react when code reviews take a lot of time and can get disrespectful?

Anonymous User at Taro Community profile pic
Anonymous User at Taro Community

I am on a tight deadline to deliver an impactful and complex feature. Whenever I send my PR out for review, my lead takes at least 2-3 days to start reviewing the code. Then, there are either a lot of non actionable comments or feedback on tests. So I started sending out a test plan in advance which also receives a lot of feedback. When I turnaround with a refined PR, the lead again takes 2-3 days for a review. I am worried that there are too many iterations for a simple PR and I am chasing the lead for reviews. When I hinted about the review taking time, I got a response that the code shouldn’t have had so many flaws to begin with. The code doesn’t have bugs, he was nit picking on unit tests that could be refactored for better maintainability. I agree, but should that be a show stopper?

I had my code reviewed by a peer and received feedback that there are no blocking changes and the code is mergeable. For a complex feature, I expected 1-2 iterations but each iteration is draining and am starting to wonder if I am really that bad an engineer. The biggest problem is that the reviews happen in person and the reviewer gets nasty and yells at times. He is extremely rude and after a few minutes he tries to explain that all the feedback is for my own good like I'm a kid. I expect some amount of professionalism but I feel disrespected because of the attitude. Is it normal for 2-3 iterations for a slightly complex PR and should I have to chase reviewers each time? Do you any tips on handling the behavioral issues?

Show more

Learn About Code Review

Code review is a fundamental part of software engineering. It is a process where engineers review each other’s code to improve its quality and receive feedback. Code review gives your teammates the ability to look at your code closely and catch potential mistakes and bugs early on. This can help stop small issues from turning into larger issues later on. Code review also increases awareness of what teams are working on, encourages cross-pollination between teams, and facilitates discussions about coding standards.
Code review allows you to share knowledge with your team about industry and team best practices. You can uplevel each others’ skills by offering feedback on how to make each others’ code better. You can ensure consistency of code by ensuring contributions to the code base follow the same patterns. When the codebase follows the same patterns, it’s easier to understand, maintain, and grow a project.
There are clear guidelines you can follow to improve your code review process. You should set clear goals for code review by specifying what you want to achieve, usually maintaining high code quality, sharing knowledge, and making sure everyone uses consistent coding patterns. This will set the stage for a focused code review. Give feedback that will improve your teammates’ coding ability instead of just pointing out problems. You should always provide suggestions on how to fix the problems. You can make the code review process smoother by using tools that automatically check for common issues, like code style. These automated tools can catch problems that can be missed in a manual review.
There are some common mistakes and traps that people follow into during code review. You don’t want to focus too much on the nitpicky code style. You should have a discussion once about code style, then you should automate it away which will lead to consistent enforcement of the rule and save your team time so they don’t need to constantly look for code style mistakes.
Pay attention how you give feedback because code reviews involve people. You should be positive and considerate when reviewing other people’s code. Recognize the effort put into the code and create an atmosphere where everyone feels encouraged to work together.
As the code author, you should develop a sense of empathy for the person that is reviewing your code. This means making the review process as smooth as possible for them and being grateful for the time they spend reviewing your code. This can mean adding context in your pull requests and including before and after screenshots.
Remember that code review can have many benefits in software engineering. It helps to keep code quality high, encourages teamwork, and it makes sure that everyone follows the same patterns. Software engineers can use code review to boost the overall success of their development efforts.
Show more