DEV Community

loading...

How to have better code reviews & tips for junior developers

mohanarpit profile image Arpit Mohan Originally published at insnippets.com ・2 min read

TL;DR style notes from articles I read today.

Code reviews at Medium

  • 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


How to be a better code reviewee

  • 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


Just keep coding! - A letter to junior developers

  • 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


Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

Discussion (5)

pic
Editor guide
Collapse
mfarajewicz profile image
Mirosław Farajewicz

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.

Collapse
arey_abhishek profile image
Abhishek Nayak

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

Collapse
mfarajewicz profile image
Mirosław Farajewicz

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
Collapse
lucasromerodb profile image
Lucas Romero Di Benedetto

Thanks so much for writre this post. It's very helpful 🙂

Collapse
mohanarpit profile image
Arpit Mohan Author

Thanks a lot Lucas! Glad you found it useful.