How to have better code reviews & tips for junior developers

#todayilearned #beginners #career

TL;DR style notes from articles I read today.

When making a change that affects the UI, include a screenshot, and preempt questions.
Add a description of why the change you made was needed.
Encourage quick reviews (at least one person responding within 4 hours).
Build in small increments and request small PRs to move faster.
Promote a ‘safe to try’ culture where developers feel free to make a call on which approach of solving a problem they take.
Code reviewers don’t act as gatekeepers. They act as enablers.

Full post here, 5 mins read

Write tests before committing the code. Submit code and then test it together for review.
Use descriptive commit messages. Group similar changes with a description for each group.
Limit the code to review so that your reviewers are not too overwhelmed and have time & patience to consider the logic & depth of your code.
Don’t take comments personally. Provide resources and arguments to defend your choice if you believe you are right.
Take difficult problems or conflicting views offline. You will achieve consensus faster by discussing in person than over comments.

Full post here, 5 mins read

Develop the willpower, voraciousness, and ambition to learn more and the willingness to go the extra mile.
Building a solid developer career is not easy or quick but the three most important factors are in your control: self-motivation, self-discipline, and focus.
The beginner stage is hard in terms of getting, retaining and understanding lots of information every day.
Enjoy the process, rather than focusing on the results.
Plan first, then code. When working on a problem, think of the different ways to solve it and don’t just go with the first solution you think of.

Full post here, 5 mins read

Top comments (5)

Good and important suggestions taken together.

I'm extremely surprised that there is little articles about code-reviewing culture. Not only on dev.to but generally on the internet.

That's true. I'd like to write a post about code reviews. What would you like it to include?

It's hard to decide as it's pretty personal. Many companies have slightly different standards. But I would say

the process itself: how many people in the team do one review, pre/post commit review
way of discussion - written / spoken. Longer elaboration (eg. "this code should be extracted to separate method XYZ and the duplicated piece from ABC should also be replaced) or short (eg. "duplication") hints
best tools, except the obvious choice of GH/GL/BB pull requests
things you should check or you should ignore ( code styling if some kind of static analysis bound to repo)
argues solving