DEV Community

Discussion on: How to tell a Junior Dev that what they've done is wrong?

View post
Collapse
 
scottshipp profile image
scottshipp •

Here is the approach that I take, which has received good feedback from multiple junior developers that I have worked with.

  1. Think about if you have an objectively good reason for your feedback. Avoid "we always do it this way" or "at ${our-company} we like to...". Those are bad reasons. What advantages do you actually get out of it? Junior devs can actually teach you something (even if inadvertently) this way, because you have to actually think about, and then put into words, the real reasons why some practice is beneficial.
  2. Provide these reasons in positive terms. For example, don't say something like, "It's wrong to add dependencies when they're not needed because then it's inconsistent with the rest of the codebase." Say instead, "we benefit from reusing work the team has already done, and from remaining consistent throughout our code base. So since we already use ${name-of-library} in X class and Y class, we can do the same thing here and that keeps us consistent and even allows us to reuse Z utility class."
  3. Don't mention anything more than once. For example, in a pull request, don't put a comment about an issue on one line, and then on every other line where the issue appears, "same here" or "fix this too" or whatever. Just put the comment in one place, and write something like, "there are a couple other places where we can improve the same thing."
  4. Get it right the first time. Especially for code reviews, don't just bomb a bunch of requests for improvements to a PR and then later when those things are fixed, go over it again and bomb some more requests down. The first time you go through, capture everything you really want and then hold your tongue. I haven't seen anything more toxic and deflating than endless commits on the same PR and junior devs never getting their code merged because of a senior dev holding it hostage (even for valid reasons). If a PR is opened that is so bad it's unavoidable, then (see next thing...)
  5. Pair program it. If you have a junior dev opening PRs full of egregious mistakes, well, it's time to sit down at an IDE with them and implement the story, while talking out loud about your reasoning. Again use the above.
  6. Let it slide. If what you have to suggest on a PR is a nitpick, then just ignore it. Junior devs don't need to get every little thing perfect. Code is always being improved anyway, and if you go back and look at code you wrote a year or two ago, you will find plenty to nitpick.

Most of the way I think about mentoring junior devs is the same for anybody else too. And I picked up a lot of great advice from Philipp Hauer's article, Code Review Guidelines for Humans