Hi HN,<p>I'm a junior engineer at a startup and I was hoping to get some tips on how to reduce the number of comments, number of bugs found, basically reduce the back and forth needed and improve quality of my code during code reviews?<p>Would love to hear specific, actionable advice from other engineers. Tech stack, if relevant, is RoR, React, PostgreSQL
You should expect some pushback on your pull requests, particularly early on. It’s a good opportunity to learn, and a good sign that your team cares about code quality and continuous improvement.<p>You mention bugs specifically, for which I think the best remedies are good unit tests and careful consideration of edge cases (which often go hand in hand). Other smaller issues such as deviation from framework conventions and performance problems can be helped by getting to know your languages, frameworks and database better, which comes with time. More generally, there are lots of good resources out there to help you improve the readability and structure of your code - Clean Code by Robert Martin (particularly the earlier chapters) and Sandi Metz’s books and talks are both good starting points. Issues with your general approach to solving problems are harder to address, but reviewing others’ code, learning about design patterns and pair programming can all help here.<p>In terms of actionable advice, I’d encourage you to briefly discuss your intended approach to a problem with a colleague before starting work: this can help expose issues in advance. Even better, pair program on the implementation with another engineer. Just pairing on the review can also help to reduce the back and forth and get code shipped faster.
The most important thing to remember is the benefits of code reviews. They're a great way to learn, help the team arrive at a common perspective on how code is written for the organization, and improve the quality of the product. You're fortunate to be in a company that takes code reviews seriously.<p>On bugs, those are opportunities to write unit tests that reproduce the bug, fix the code, and prove that the bug no longer exists. After a while, you'll be able to recognize how to avoid bugs specific to the type of things you've done in the past. If it helps to know, you'll gradually get better, but even the best/most experienced/smartest people can have bugs in their code.<p>To summarize, don't feel bad or inadequate for making a mistake. Appreciate the fact that someone cares enough to help you improve and they also care about the company that they take the time to do good code reviews. You'll get better.
May sound a bit generic, but here is what I advise junior devs when joining the team:<p>“Don’t just read the code guidelines, try to search the ciérnase for a similar case to the problem you are solving and apply the same principles. Generally, look around and make your code blend. Then review your own PR, sometimes it’s easy to spot mistakes when looking at just the diff.”<p>In addition, I tend to repeat myself a ouch times so they “get it”, but I do expect not to have to point out the same mistake over and over again, so pay attention to what’s pointed out during review and remember it for future reviews!
I think testing would be helpful for the bug part. Catching bugs is always a pain and isn’t the job of your seniors, although sometimes things slip in. It’s good to test your code thoroughly so at least you are confident your code works correctly. Although time constraints sometimes don’t allow for extensive testing, some basic tests would be useful.<p>Full disclosure working on <a href="https://www.superadmin.so" rel="nofollow">https://www.superadmin.so</a>. Trying to help with making e2e testing easier.