Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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!
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
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.
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. 🙂
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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?
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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.
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!
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
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.
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