DEV Community

Keff
Keff

Posted on

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

I struggle with this a lot, how do you approach this? How do you explain that what they've done is wrong, it affects the rest of the team, and that they should think more about the problem and side-effects? Without affecting their confidence and morale too much by doing so. I'm always afraid of affecting them negatively...

What if the issue is recurrent and happens on most tasks they're assigned to? Not too bad as to justify a layoff, but enough to increase development times.

How do you deal and communicate these things?

Cheers! Waiting for your helpful advice as always!

Discussion (55)

Collapse
inhuofficial profile image
InHuOfficial • Edited on

Ask the person directly how they prefer to receive constructive criticism.

I like blunt and to the point (this is wrong, do this instead) and early (if you can see I am about to take a wrong action, tell me then rather than letting it get to the point the damage is done).

Most people would prefer a softer approach, some would prefer you give them a heads up in a message before talking with them so they can get into the right frame of mind and not be defensive before taking criticism on board etc. (if you start a conversation without prior notice on something that needs improving, even welcomed feedback can get a “gut reaction” response and make someone defensive)

The point is to ask!

Also a universal truth is give them the “why”. Why was this incorrect, what impact does it have on the team, bow or in the future etc.

This last part is the bit I am bad at and working hard on at the moment. I ask a question or give my opinion too quickly and without the context of why this matters and why it should be done differently!

Collapse
nombrekeff profile image
Keff Author

Okay, little update just FYI. I have to thank you for the tips.

I just asked them how they wanted to receive criticism, as I felt uneasy, and the reception has been fantastic. Not at all the response I expected.

This is why I love this community!

Collapse
inhuofficial profile image
InHuOfficial

I am so glad it helped. ❤️

But I am just imparting wisdom taught to me by smarter people, I take no credit 🤣❤️

Thread Thread
adam_cyclones profile image
Adam Crockett

Wisdom Official

Collapse
raibtoffoletto profile image
Raí B. Toffoletto

As a junior myself I prefer this approach as well. But the why is important because there's WRONG and there's "the way we do it". If you don't convince me that my research and way of thinking is not the right approach I'll comply with the criticism and norm but in a next project/team I'll fall back to my initial ways. 🙂

Collapse
inhuofficial profile image
InHuOfficial

A very important distinction there on why you must focus on the "why" (what a weird sentence 🤣)

Great point to consider!

Collapse
nombrekeff profile image
Keff Author

Cheers, it's super cool to hear what the other side has to say.

Collapse
nombrekeff profile image
Keff Author

Thanks @inhuofficial

Interesting, I had not considered asking how they prefer to receive constructive advice, it's a nice angle to look at it. I will probably make use of this.

I also like the point on giving them a heads up first, this might be something I try and see how they respond!

In respect to giving context and a reason why, I totally agree with this. This is something I tend to do, maybe not enough though. I always try to put into prespective how it affects us all as a team, and why it's our responsability as developers to make sure you test and think about the given problem or task.

Collapse
subuhunter profile image
SUBRAMANIAN

This is a great tip @inhuofficial , thanks!

Does this rule apply for telling senior devs too. I'm someone with 8 yrs of exp. I've seen some of my colleagues at work who are more expeirenced than me are still doing some basic amature mistakes. How do I tell them in this case?

Collapse
inhuofficial profile image
InHuOfficial • Edited on

Tougher with seniors unless you are also a senior or have worked with them long enough and closely enough you know how to frame things with them.

The same principle applies of knowing how they prefer to receive feedback but you have to also occasionally (not often I would hope) work around “seniority complex” as I call it 🤣.

Best bet is similar approach, but when actually addressing the problem go very much evidence based. Find articles from authority figures, or stats on how much time doing X would save or show them how you did it and explain why you think it would benefit the team if you all did that going forward.

Also “give them breadcrumbs” to lead them down the path you want them to take. Don’t tell it to them as “do this”.

Do “I noticed you do X, but I was reading this and this that said to do Y instead. Can we have a look at this together?” And then make your case.

Most seniors will take everything on board and welcome it, you just have to bear in mind they have had 30 people tell them the best way to centre a div, so if you are number 31, you better make sure you show them why your approach using X is better due to greater browser support, better consistency in results and flexibility etc.

Also note this is very much for the few senior devs who everyone knows are awkward. For 90% of them same principles apply, I just wanted to give you a framework that works for those who are less open to feedback.

Thread Thread
subuhunter profile image
SUBRAMANIAN

gotcha! That totally makes sense. Thanks again for the tip @inhuofficial

Collapse
leob profile image
leob • Edited on

I know of one example from a company where I worked and we just had to let the person go after a week, it was unbearable, lol ... if the junior is any good then they will ask THEMSELVES (proactively) "do you think I did anything wrong - if so, please do tell me!"

So the answer to the question posed in the title would be: you'd just tell them straight to the point, because that's exactly what they'd want.

And if they're good then intuitively they'll ask for advice BEFORE they're about to make any egregious mistakes, and thus avoid those.

Of course people can make mistakes, but if someone needs continuous handholding and they're not proactive and don't have the intuition that something might not be the right choice or approach, yeah then you'd have a problem.

Collapse
nombrekeff profile image
Keff Author

Cheers, thanks for taking the time to help out! I much apreciate it.

This gives me a bit of prespective, and it's something that's always on the back of my mind. Though I always give people a couple of chances before going to that extreme. Always hard to deal with this stuff innit?

Collapse
leob profile image
leob • Edited on

I can understand that it might be hard but I'm always frank (trying not to be blunt, lol) ... a good junior is eager to hear the truth coz they wanna improve ... you don't need to be harsh or mean but no need to sugarcoat it TOO much, just tell it like it is, and a good junior will even appreciate it - coz they wanna improve ... I mean, if nobody's telling them things just the way they are, then how can they improve?

Thread Thread
nombrekeff profile image
Keff Author

That's exactly what they told me when I asked them what inhu adviced, asking them how they prefer to receive constructive criticism.

It's the same case as, how will I know if I snore if nobody tells me. Or that my breath smells like crap if nobody says so!

Thanks again!

Thread Thread
leob profile image
leob

Haha okay ... well you hit the nail on the head - it should be CONSTRUCTIVE criticism, it should not be about putting someone down or denigrating them, it's only about the work they've done and what they've produced - with the explicit goal for them to learn and improve.

Thread Thread
nombrekeff profile image
Keff Author

That's it, the goal is to learn and improve! And that they know that's the goal too!

Collapse
shikkaba profile image
shikkaba

Sometimes there are people who don't know they are doing something wrong unless they are told, and they ask what they can work on and get vague answers. I'm in this position with myself. Had something happen once and was told to fix it, but not directed how to do so. I like to at least be pointed in the right direction if it is something I didn't know in the first place.

Collapse
leob profile image
leob

Well in that case it's the "senior" who's the one who's clearly falling short, obviously it's not always the junior's fault! :)

Collapse
nombrekeff profile image
Keff Author

Thanks for your view, it's interesting to understand the point of view from the other side!!

Collapse
natescode profile image
Nathan Hedglin

Wrong as in immoral of wrong as in a mistake?

My developers and I discuss their code regularly during pull requests. If there are other issues, work ethic etc then we'll discuss them. I'll ask why it was happening, how I can help and state I expect the behavior to change.

Collapse
nombrekeff profile image
Keff Author

Wrong as in mistake, not only in code, but in the whole development process, like not doing proper testing, ingoring side-effects, and not viewing the whole picture (although most of this comes naturally with experience). Though in this case in particular, the issue was not taking the time and effort to polish a task, extending development times.

I like this approach, do you do this on each PR? And do you talk in the PR directly or by personal or voice chat?

Collapse
natescode profile image
Nathan Hedglin

For small suggestions, I'll comment on the pull request. For more complex comments, or if they continue to make the same mistake, I'll do a video chat with them.

Thread Thread
nombrekeff profile image
Keff Author

Good stuff, I think I might apply this into my reviews too! Seems like a good way to go about it, I tend to comment eveything on the PR and I might not always make it clear.

Collapse
pavelee profile image
Paweł Ciosek

Hey!

Just use a feedback sandwich!

First, find something good in the solution. Just say eg. “You formatted code well!” (Top part of the sandwich)

Second, elaborate what is wrong in the solution. Important! Always have the better solution to present! Saying the solution is but because you don’t like it is not really helpful. (Middle part of the sandwich, most valuable)

Third, say something positive in general, eg. “you doing well!” (Bottom part of the sandwich)

In my opinion it’s the best way to pass your feedback. Positive communicate is really important to open up junior developer for your feedback.

Cheers! ❤️

Collapse
andrewbaisden profile image
Andrew Baisden

Give them constructive feedback but in a nice way and try to make it as positive as possible for them. Explain that other team members made similar mistakes too when they were at that level and its something that will improve with time and experience.

Collapse
shaneikennedy profile image
Shane Kennedy

If I have an opinion on why I think what any of my team members did wasn't the best direction, I try to ask leading questions to help them arrive at my underlying concern for why their solution isn't the best way forward. This way they get to do the thinking themselves which is good experience in itself, but also I find that they feel better about going back and fixing their solution than if I had just told them how to make it better

This is something I initially tried out because when I was junior and a senior would tell me "this isn't good because x,y,z" I would feel dumb for not already knowing things, but as I learned later, being senior isn't about knowing everything, it's about having learned to ask more/better questions (albeit questions that you learn to ask through experience). At least in some cases I find this to work well :)

I also really like @inhuofficial 's answer and will give this a try next time

Collapse
inhuofficial profile image
InHuOfficial

I like the leading questions bit! Much better to let people connect the dots themselves as they get a better picture of everything, rather than a "don't do that" without the why. ❤

Collapse
brojenuel profile image
Jenuel Oras Ganawed

when I was a junior, one my of senior actually teach me, and always tell me to ask them If I am stuck on something, they also told me that I should not be afraid to ask etc. and they said they are happy to teach me new things.

Collapse
nombrekeff profile image
Keff Author

Good leader that, always be open to help and teach. This is something I let them now when they join and remind them a couple of times until they're not afraid of asking. Though sometimes, in periods where we might not have the time or energy to teach or do pair-programing etc... some tension can be created. So by reminding them and being there, we can keep tension and such under control.

Collapse
jwhenry3 profile image
Justin Henry • Edited on

Trying to be short and sweet with my answer:

  • Inform them in a short way why the approach taken has negative side effects (and site the source if possible)
  • Inform an alternative approach that would yield more desirable results and explain why (clearer code, easier to maintain, smaller memory footprint, etc)

Basically you are not arguing what is wrong and right, you are expressing your opinion on how it can be improved. This is the approach I take when helping others and how I expect to be handled when being corrected as well.

When you simply say "its wrong" and don't do the diligence of providing explanation and direction, you are missing an opportunity to educate without coming off as pompous

Collapse
nombrekeff profile image
Keff Author

Totally agree, I'd never say "it's wrong" without providing extra context and explanation on WHY it's wrong.

Collapse
stegriff profile image
Stephen Griffiths

Just to add; my expectation for Juniors would be:

  • Complete very simple work unaided, given adequate instructions
  • Complete moderate complexity work with help (pair-coding)

My training scheme for juniors on medium complexity work is:

  1. You watch me build it (I'm driving the screen and thinking out loud about design choices)
  2. I help you build it (You're driving and I'm doing a mix of leading questions and literally telling you what to type -- this develops muscle memory)
  3. I watch you build it (You're driving and thinking out loud and I tell you when you're not quite right)
  4. You build it on your own and ask for help if necessary

We gotta set juniors up to succeed. This means plenty of training wheels, lots of written instructions, and a conscious mentoring program like the above!

Collapse
nombrekeff profile image
Keff Author

Cool stuff, I will take inspiration from this scheme for sure! Thanks a lot for sharing

Collapse
sublimegeek profile image
Jonathan Irvin

I agree with being straightforward. It saves time on both parties especially if the feedback is clear.

When giving review feedback, always offer alternatives by means of a code block. Ask lots of questions and have them explain their thought process behind it all.

On my team we're trying sort of an "alley-oop" method where one of the seniors goes and writes some tests that recreate the bug/defect and have the dev keep working until the tests pass.

More important than criticism is positive reinforcement. Let them know what they are doing right and well. Give them praise in public.

I will ask, though, is the way you want the dev to perform not aligning with how you want it to be done, or the standards set for the team? Do the standards of the team need to be calibrated for better quality and more automated confidence?

Collapse
nombrekeff profile image
Keff Author

Thanks for your addition! Positive reinforcement is always good, I try to do it as much as I can (within a limit, otherwise it can lose it's meaning)

I will ask, though, is the way you want the dev to perform not aligning with how you want it to be done, or the standards set for the team? Do the standards of the team need to be calibrated for better quality and more automated confidence?

A bit of both, we're a small company and don't have many standards in place currently (we're working on it continously), it's somewhat my job to enforce them. I try my best to be as impartial and objective as I can, I will not enforce stuff just because I don't like it, I try to enforce good practices and prevent them from adquiring bad habits.

Collapse
gewenyu99 profile image
Vincent Ge

Focus on the problem. Remove who did what, just explain the mistake.

"Look at this bit of code, notice this pointer that was never deallocated. That causes a memory leak."

That's the criticism.

If it's about conduct, you can instead focus on the action and it's affect on the team.

Say:
"Hey, do you have a moment? So earlier you had your phone out and was watching TikTok during the meeting. Having TikTok play during a meeting is distracting to those attending the meeting. Preferably we'd have the meeting in peace."

Instead of:
"Hey, do you have a moment? So earlier you had your phone out and was watching TikTok during the meeting. What you did during the meeting is distracting to those attending the meeting. Preferably you would let us have the meeting in peace."

Just stick to the facts and avoid excessive finger pointing. Explain what happened and it's affect and avoid being overtly personal. It's the actions, not them, but they should understand to avoid it down the road. I think as a professional, they should pick up on the constructive criticism non the less.

Collapse
nombrekeff profile image
Keff Author

Great tip, change the YOU with IT or WE. I could not agree more, this is something I picked up a time ago reading some post here on DEV, and have tried to apply it as much as possible. It can make a huge difference on how people interpret the criticism.

Collapse
thenickest profile image
TheNickest

Work together with the junior dev. Teach the younglings. Reflect on yourself and ask: how do I deal with feedback? How do I want to be approached. You’ve been there too. Lay out the facts and be specific why something is wrong and how it should be done or even must be done. It’s part of our lives, our jobs. But not saying anything is bad. I’ve been there too recently and changed ever since. Give others a chance. Only after x times, when it seems hopeless a lay-off might be the only solution.

Collapse
maulik profile image
Maulik

Discuss few cases where junior's code will fail and ask how his/her code will work in such scenarios. That way he/she will learn and will keep these kind of scenaios in mind from next time and they will also be greatful as they've learnt something from you each time.

Note : Don't tell them exactly what to do, just put such test-cases or scenarios on which they can think and code.

Collapse
nombrekeff profile image
Keff Author

Good stuff, this is something I do currently, seems to have a good effect. It makes them feel like they found the problem themselves. This was also mentioned in another answer, that we should try to guide them so they found the problem or solution themselves.

Collapse
preciouschicken profile image
Precious Chicken

Kind of tactical but when you are actually delivering the constructive criticism you could sandwich it: so make a positive statement (e.g. you're doing great work on x), the key negative statement (e.g. but you could do y differently) and end with another positive statement (e.g. you're proving a great fit with team z). This obviously has to be sincere / genuine; but hopefully they take onboard what they need to do better while still feeling ok about things. After all most people want to go to work and do a good job.

Of course if you've got nothing at all positive to say, you've got a different problem...

Collapse
nombrekeff profile image
Keff Author

Excelent addition, this is one I already apply, as I value it when the same is done to me. We, as humans, tend to focus on the negatives and not the positives.

Collapse
laurentld79 profile image
Laurent Dumas

I'm an empathic person, so i tend to use that kind of soft skill to help situations like that.
I'm also use questions in a way to trigger a thinking in the developer head (like Inception's concept :p). In a long run, he ask himself he choose a solution, and search a reason and ask himself if that reason is relevant.
Plus, every time I'm facing this situation, i try to discuss with the developer on thinking steps I am using to do that task.

One thing which I find very important, and essential, is that I say to him that find THE solution on first time, with clean code and all that is not the goal. I say to him that coding a solution, simple maybe not that great but works (which I call code of first intention), and then in a second time, refactoring is better. I think it is better and demands less efforts.

Beside all of that, asking some of the time if he has difficulty or how is it going can help him asking questions to you.

Collapse
sziraqui profile image
Sarfaraz Iraqui • Edited on

You can suggest a better approach. In most cases, the person would understand the mistake and see your suggestion as an act of improving the junior dev's knowledge. If they don't understand, you can show them pros and cons of both approaches. A bad approach will definitely have a lot of cons.

As a senior dev, one should understand that a less experienced dev may not have seen multiple approaches yet. They might have just seen one approach and tried to implement it. So being blunt with a junior dev, especially a new joiner could demotivate the person. Also remember the junior dev most likely does not "own" the approach. So avoid using words like "your approach". Focus on the bad things in the approach and not the person.

You can be blunt with colleagues who are also your close friend, when you know how they react to criticism, but being blunt with someone you do not know much can have a lot of negative impact on the person's mental health.

Collapse
smonff profile image
🌌 Sébastien Feugère ☔

It’s not very clear what is this notion of « wrong » although I can imagine many possibilities. And in your organization, if something is wrongly done, maybe give your colleagues more ways to do it the right way. It can be training, code review, documentation. People will observe and learn.

Actually, I think telling people « the wrong things » won’t help much. Showing good practices and fair behavior would have a stronger effect.

Collapse
heatherw profile image
HeatherW

I like to see mistakes as a teachable moment and try explain why the mistake occurred or how to prevent it happening again. Having a culture of openness and learning really helps for this approach.

It helps for juniors to see seniors making mistakes and learning from them too which enforces a learning mindset. So I always try to be open and share my aha moments with the whole team, especially when I made a mistake.

Sharing knowledge amongst the team is also great, at the company I work for all devs get to see all levels of conversation (easier in a small team though). For example we include our most junior dev in discussions that often go over her head but that then leads to her asking really great questions about why things are done the way they are. And there are no dumb questions in our company except the ones you don't ask.

Sometimes a person has just plateaued in their job and you either need to give them different work or help them move on to another company. I have seen this happen to one of my colleagues and in the end it was best for him to move on to another company to try something new.

Collapse
mvuorinen profile image
Mikko Vuorinen

When there's enough time given to the whole team to help everyone grow, this is the approach I try to take in situations where someone's done something that doesn't look right:

  • Let them take you through what they've done and explain why they ended up doing it like they did
  • Ask questions to make sure they explain their decision making
    • "Why did you decide to use X?"
    • "What did you assume about Y?"
    • "Are there other ways of doing this that you considered?"
  • If you think they might have missed something, ask questions that will make it easier to see
    • "What happens to Y when you do this to X?"
    • "In what kind of situation we end up here [line of code / method / API endpoint etc]?"
    • "Would this also work in situation Z?"
    • "Do you know about this [tool / library / documentation etc] that might be related?"

It's really impactful to have the person discover themselves where they've gone wrong and figure out a better way of doing things, with someone more experienced just gently nudging them to that direction. Try to avoid just giving them your "correct" way of doing things.

Make sure to be genuine when asking questions. You might have an answer in your mind, but you may have missed something or don't know something they do, so listen when they give you their answer. More often than not it's a learning experience for both sides.

The example questions above are just something I came up with, and they can be anything that fits the situation, the type of work being done, and the experience level of both of you.

One thing to note is that this is quite mentally demanding way of solving this kind of problems (because it's more about learning than fixing). Try to be aware when they or you don't have the energy to push through it, and find other opportunities for it, especially if it's a recurring problem.

Collapse
philthedev profile image
Philippe Batigne

This is something I struggle with, regardless if they are junior, mid level, or senior. I would start off by saying; receiving critical feedback will be the single most thing that levels them up in there career and the fact that you care will make them a better developer.

What I would do in this instance, would first say something to praise the work in some capacity; maybe they took some initiative even if it was ill-informed or they got into a code base that was naturally tricky and give them props that they were able to get work done period.

Second, mention that there are some pitfalls or issues that you saw earlier in your career or something that other devs in that company/workplace/team have also done. This is where bringing up concrete anecdotes or articles to boost where you're coming from. Bringing up issues as "hey, it's okay you made these issues, people have done that before" makes them feel they're at least on the right path.

Third, ask them for the next task to request an early review or set up a meeting to do a review in real time. Doing a real time review will be easier to figure out the "why" and help course correct using mental patterns they're already using. This will help avoid this particular situation again where you're trying to give feedback after the fact.

Collapse
liviufromendtest profile image
Liviu Lupei

Tell them to post on Reddit about it.
No, seriously.

Collapse
nombrekeff profile image
Keff Author

Hahahaah funny, did not catch this one when you posted it 🤣

Collapse
sherrydays profile image
Sherry Day

Probably the way you would like to hear this type of feedback — as long as you can be completely honest with yourself about how you might react negatively to it being delivered in an unhelpful way.

Collapse
biosbug profile image
Roberson Miguel

I believe that a junior depends a lot on support and tasks with high turnaround times could be resolved in the daily before it becomes a problem for the team.

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

Collapse
rnkrnk profile image
RN • Edited on

Without affecting their confidence and morale too much by doing so.

And this is how we get "snowflakes" en.wikipedia.org/wiki/Snowflake_(s...

If you take care of their sensitivity so much, how will they deal with serious problems in the future?

I do not mean that you can yell and swear at employees. But do not be afraid to be strict, because this is a job, not a kindergarten. And if a junior starts complaining about "toxicity" just because of direct criticism, then he may not belong in this profession, and he needs to look for a less stressful job. I personally would not want squeamish and pampered people to write life-critical software.

Collapse
sirseanofloxley profile image
Sean Allin Newell

Focus on the results; why is it wrong? What do you suggest instead and what is the consequence of doing it right?