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!
Oldest comments (54)
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!
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.
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!
I am so glad it helped. ❤️
But I am just imparting wisdom taught to me by smarter people, I take no credit 🤣❤️
Wisdom Official
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. 🙂
Cheers, it's super cool to hear what the other side has to say.
A very important distinction there on why you must focus on the "why" (what a weird sentence 🤣)
Great point to consider!
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?
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.
gotcha! That totally makes sense. Thanks again for the tip @inhuofficial
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.
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?
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?
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!
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.
That's it, the goal is to learn and improve! And that they know that's the goal too!
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.
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! :)
Thanks for your view, it's interesting to understand the point of view from the other side!!
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?
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.
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.
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...
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.
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.
Just to add; my expectation for Juniors would be:
My training scheme for juniors on medium complexity work is:
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!
Cool stuff, I will take inspiration from this scheme for sure! Thanks a lot for sharing
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?
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)
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.
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.