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!
Latest comments (54)
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.
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! ❤️
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.
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.
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.
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.
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
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. ❤
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.
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.
Trying to be short and sweet with my answer:
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
Totally agree, I'd never say "it's wrong" without providing extra context and explanation on WHY it's wrong.
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.
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.
Focus on the results; why is it wrong? What do you suggest instead and what is the consequence of doing it right?
Tell them to post on Reddit about it.
No, seriously.
Hahahaah funny, did not catch this one when you posted it 🤣
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:
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.
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.
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.