One thing is to automate the code review when it makes sense. For example using black, isort, pytest, pylint, flake8, commitizen, and/or mypy. Not saying to use all of these. Feedback from a computer saying something is wrong is much easier to handle than a person telling them something is wrong.
Great video Arjan! I totally agree with you. I have actually made a big career switch last year and went from a senior management situation in a broadcast media and video production environment to a Junior software development position. In my previous role I had to give feedback to juniors a lot. I regularly had interns to guide and coach at video editing, directing, camera operating, etc. Now I'm usually the one receiving feedback, which I find great. The insights I have about GIVING feedback actually helps me a lot being a good receiver of it ;) In Dutch we like to say: "feedback is een cadeautje!" (I.e. "feedback is a present, treat it as such")
I've been at my current job for 2 years. This is the first job I've ever had where there are developers less experienced than myself. I have been so clueless about how to handle that! I can get really worked up about "bad" code and often don't know how to react appropriately. Thank you for this video, there's some helpful stuff here!
Your most useful video for me. I can learn good programming from a book, but only a human with experience can communicate properly how to treat people well.
Excellent advice and very well presented. The view count for this video is lower than it deserves, and I assume that is related to the feelings I felt when I saw the thumbnail. I assume a lot of your regular viewers have experienced being torn down by a bad manager or more senior engineer, and an overlapping subset of your viewers have also been the bad manager/senior, and people don't like thinking about being either hurt or hurting others, causing potential viewers to scroll past. I think you could get more eyes on this if you went with a visual metaphor for "building someone up" or "mentoring people to lightbulb moments" or something that would make the potential viewer think of the great mentors they've seen/loved working with in the past. I absolutely love helping junior data scientists/analysts at my job as A) it feels amazing to help people connect concepts and develop a robust understanding, B) it feels like getting to talk to myself a few years in the past and show them a faster way, and C) I've developed a network of peers who come to me with interesting projects who I can trust to do good work. Anyway, I avoided this video for a few days because of how sad I felt seeing the under-attack Arjan in the thumbnail, thinking about the bad manager from my past. I think you could get this valuable content in front of more eyeballs with a new thumbnail.
Personally I hate the indirect feedback models like Pendleton, and CEDAR somewhat. A lot of the times the Reviewer comes across as passive aggressive and makes the Reviewee feel like they're in the hot seat and have to identify what mistakes they made and what they should do differently, otherwise come across as an idiot. With open ended questions I know you're probably thinking of something specific so my mind starts panicking and searching as to what that is. I'd much rather have that two hour session where I'm directly told what I've done wrong and what I should do to improve, I find there's nothing wrong with direct *constructive* feedback.
I think what you describe is not how it is meant to be done. The idea is to get into a constructive discussion, not to blame the reviewee or show him his incompetency. Rather ask open questions you are really interested in. Like what was your idea behind this code. If the reviewer is open minded, he might even learn something. Or you can say something like „I like the approach but look at xyz, the stdlib provides a different very easy way to doing the same thing which is more concise“
Somewhere you mentioned to not point out too many things at once. I see what you mean, and how pointing out (even friendly/constructive) can be overwhelming. But how do you make sure the quality of the code base doesn't degrade when you allow bad code / future technical dept to get merged? Do you simply have to accept that the quality of the code base is always a reflection of the combined level / skills of the development team? How do you find a good balance in a team between giving juniors the chance to learn (and fail)a nd have some responsibility while still maintaining the required level of quality?
Good question, Bram! Next to not pointing out too many things at once, you also have to make sure that the scope of the things you assign to juniors matches their skill level. So start with asking them to do minor code changes and address the main issues in the code review, and then as the junior learns to deliver good quality code on a small scale, up the level and let them work on larger projects.
I'm not a professional developer, but I do write code that gets used by others. What bugs me is that the actual developers of the data storage/visualzation platform that we interface with, are useless at providing documentation or feedback with regards to how to optimise our Python code for this platform. Occasionally, they say "don't do it that way", and when asked why, they will not give reasons (presumably because they think we are too stupid to understand), and nor will they explain a good way either. I expect this poor attitude from individuals, but it's the same thing when talking to any of the team. On paper, we all work for the same company, but in reality, it's horrendous.
Thanks for this video. Do you think XP is more efficient that waiting for a pull request? In a similar way that writing code tests before the implementation code is more efficient.
when i studied to become a teacher, the lecturer said always use the sandwich method. Which is give positive feedback first, then the negative feedback but, end on a positive one. Like "I like how you write your code it is easy to understand. But, dont keep everything thing in one class/method. Otherwise keep up ur good work" for instance
Embrace low quality 'cause most of the coders / programmers / software developers / software engineers are juniors. (Plus, most of the code is legacy, 5-10-25 years old - while good refactoring is mastery.) And the junior's volume, and the proportion, is increasing. It takes a few years to get to a medior level, and another few to gain the senior experience and knowledge - if someone has the personal ambition, and a healthy self-criticism, and self-humour. It's not really correlating with the age. However, it's still better to tell them that they do an awesome job ;-) We are humans, we function in this weird way.
Didn't have the time to watch the video so I'll just use the cover image as a guide, and use a mechanical keyboard to smash the developer. Coz it sounds better right?
off topic, but a suggestion for content: It would be great if you could create a complete course on how to design software, like using design patterns, solid, etc, from scratch. You could even sell it 😜
@@ArjanCodes Nice! It's too expensive for my pocket, but I'll see it later when I can afford it. I'm not a professional developer. I code for my personal projects. Is there any possibility of a discount? 😳 Thanks.
Yes I need a feedback. I've been to a bootcamp to become fullstack dev with cringy ruby on rails as back-end stack. Then I've grinded to become a fullstack god. But now when I apply I get rejected for every company. I've asked many devs in the past : is it possible to join a fullstack even if you didnt master their back-end stack. They all said "yes" even those with 15 years exp. And now I realise that was bullshit, in my city ( which is 1.5 millions citizens, France ) there is only like 5 or 10 fullstack job offers, and among those, maybe only 3 or 4 were I could be interested. Even if Im a fullstack god, the only way to start would be to pick only "front-end" which sucks for fullstack god, work at home on their back-end every night, every week-end, and finally get the job I have the skills for. Why nobody told me the truth before ?
You forgot to say that everybody is allowed to learn and that making misstakes is a natural part of the learning process 😄 Making misstakes isn't too bad, at least if you aren't developing a "software as hardware" mess such that the code stays flexible to make adjustments 😂😂😂
While it'd true that Meta, and twitter programmers are out in the job market now, I don't know if firing people is the right way to grow the industry as a whole. Sure it's probably better to hire good engineers, but when you hire juniors you're not getting top level programmers.
A workplace that wants to retain its employees needs to help them grow. Hell, some of the best engineers I know started as (paid) interning college students that were given job offers on graduation.
If you think so, go ahead. You'll probably quickly earn a reputation for a toxic work environment in said talent pool. I believe that a good feedback culture and psychological safety boost employee loyalty and lead to more success in the long term. Actually, if anyone knows about studies of such correlations, I would be very interested.
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
One thing is to automate the code review when it makes sense. For example using black, isort, pytest, pylint, flake8, commitizen, and/or mypy. Not saying to use all of these. Feedback from a computer saying something is wrong is much easier to handle than a person telling them something is wrong.
Great video Arjan! I totally agree with you. I have actually made a big career switch last year and went from a senior management situation in a broadcast media and video production environment to a Junior software development position. In my previous role I had to give feedback to juniors a lot. I regularly had interns to guide and coach at video editing, directing, camera operating, etc.
Now I'm usually the one receiving feedback, which I find great. The insights I have about GIVING feedback actually helps me a lot being a good receiver of it ;)
In Dutch we like to say: "feedback is een cadeautje!"
(I.e. "feedback is a present, treat it as such")
I've been at my current job for 2 years. This is the first job I've ever had where there are developers less experienced than myself. I have been so clueless about how to handle that! I can get really worked up about "bad" code and often don't know how to react appropriately. Thank you for this video, there's some helpful stuff here!
Your most useful video for me. I can learn good programming from a book, but only a human with experience can communicate properly how to treat people well.
Excellent advice and very well presented. The view count for this video is lower than it deserves, and I assume that is related to the feelings I felt when I saw the thumbnail. I assume a lot of your regular viewers have experienced being torn down by a bad manager or more senior engineer, and an overlapping subset of your viewers have also been the bad manager/senior, and people don't like thinking about being either hurt or hurting others, causing potential viewers to scroll past. I think you could get more eyes on this if you went with a visual metaphor for "building someone up" or "mentoring people to lightbulb moments" or something that would make the potential viewer think of the great mentors they've seen/loved working with in the past.
I absolutely love helping junior data scientists/analysts at my job as A) it feels amazing to help people connect concepts and develop a robust understanding, B) it feels like getting to talk to myself a few years in the past and show them a faster way, and C) I've developed a network of peers who come to me with interesting projects who I can trust to do good work.
Anyway, I avoided this video for a few days because of how sad I felt seeing the under-attack Arjan in the thumbnail, thinking about the bad manager from my past. I think you could get this valuable content in front of more eyeballs with a new thumbnail.
Thank you beaulinpin, glad you liked the video!
from 3:07 to 3:21 is pure gold, thanks Arjan!
Using CEDAR is not limited to programming code review. CEDAR is useful for any supervisory related functions.
Amazing video. I would love to be managed by someone that put some effort in giving structured feedback instead of just behaving as they feel works.
Amazing video! Very complete and with wonderful advice, thank you!
Personally I hate the indirect feedback models like Pendleton, and CEDAR somewhat.
A lot of the times the Reviewer comes across as passive aggressive and makes the Reviewee feel like they're in the hot seat and have to identify what mistakes they made and what they should do differently, otherwise come across as an idiot. With open ended questions I know you're probably thinking of something specific so my mind starts panicking and searching as to what that is.
I'd much rather have that two hour session where I'm directly told what I've done wrong and what I should do to improve, I find there's nothing wrong with direct *constructive* feedback.
I think what you describe is not how it is meant to be done. The idea is to get into a constructive discussion, not to blame the reviewee or show him his incompetency. Rather ask open questions you are really interested in. Like what was your idea behind this code. If the reviewer is open minded, he might even learn something. Or you can say something like „I like the approach but look at xyz, the stdlib provides a different very easy way to doing the same thing which is more concise“
This was quite helpful, my soft skills (aka people skills) are definitely less well developed then my hard skills (programming).
Glad it was helpful!
Somewhere you mentioned to not point out too many things at once. I see what you mean, and how pointing out (even friendly/constructive) can be overwhelming. But how do you make sure the quality of the code base doesn't degrade when you allow bad code / future technical dept to get merged? Do you simply have to accept that the quality of the code base is always a reflection of the combined level / skills of the development team? How do you find a good balance in a team between giving juniors the chance to learn (and fail)a nd have some responsibility while still maintaining the required level of quality?
Good question, Bram! Next to not pointing out too many things at once, you also have to make sure that the scope of the things you assign to juniors matches their skill level. So start with asking them to do minor code changes and address the main issues in the code review, and then as the junior learns to deliver good quality code on a small scale, up the level and let them work on larger projects.
Can you do a video of Python code interacting with database? Say a simple ETL pipeline
I'm not a professional developer, but I do write code that gets used by others. What bugs me is that the actual developers of the data storage/visualzation platform that we interface with, are useless at providing documentation or feedback with regards to how to optimise our Python code for this platform. Occasionally, they say "don't do it that way", and when asked why, they will not give reasons (presumably because they think we are too stupid to understand), and nor will they explain a good way either.
I expect this poor attitude from individuals, but it's the same thing when talking to any of the team. On paper, we all work for the same company, but in reality, it's horrendous.
1:55 But what if the customer really is a knucklehead? It's not really uncommon.
If clients weren't "stupid", they will not be paying you to solve stuff...
Thanks for this video. Do you think XP is more efficient that waiting for a pull request? In a similar way that writing code tests before the implementation code is more efficient.
when i studied to become a teacher, the lecturer said always use the sandwich method. Which is give positive feedback first, then the negative feedback but, end on a positive one. Like "I like how you write your code it is easy to understand. But, dont keep everything thing in one class/method. Otherwise keep up ur good work" for instance
There are opinions that, although it sounds nice, that's an oldschool and not effective approach. Also, there are studies that arrived to that result.
@@Geza_Molnar_ link to those studies
Embrace low quality 'cause most of the coders / programmers / software developers / software engineers are juniors. (Plus, most of the code is legacy, 5-10-25 years old - while good refactoring is mastery.) And the junior's volume, and the proportion, is increasing. It takes a few years to get to a medior level, and another few to gain the senior experience and knowledge - if someone has the personal ambition, and a healthy self-criticism, and self-humour. It's not really correlating with the age. However, it's still better to tell them that they do an awesome job ;-) We are humans, we function in this weird way.
Fantastic thumbnail, gave me a good laugh =]
Thank you, glad you liked it 😊
Why can't the manager just say what they want straight-up when you do something wrong? Makes it a lot less awkward imo.
Didn't have the time to watch the video so I'll just use the cover image as a guide, and use a mechanical keyboard to smash the developer. Coz it sounds better right?
That’s the spirit! Hit first, talk later 😉.
off topic, but a suggestion for content:
It would be great if you could create a complete course on how to design software, like using design patterns, solid, etc, from scratch.
You could even sell it 😜
Great suggestion!
Done! 😁 www.arjancodes.com/mindset
@@ArjanCodes Nice! It's too expensive for my pocket, but I'll see it later when I can afford it. I'm not a professional developer. I code for my personal projects.
Is there any possibility of a discount? 😳
Thanks.
I am junior developer. Why do i watch this?
360 degree feedback is all a bit too "struggle session" for me.
Yes I need a feedback.
I've been to a bootcamp to become fullstack dev with cringy ruby on rails as back-end stack.
Then I've grinded to become a fullstack god.
But now when I apply I get rejected for every company.
I've asked many devs in the past : is it possible to join a fullstack even if you didnt master their back-end stack. They all said "yes" even those with 15 years exp.
And now I realise that was bullshit, in my city ( which is 1.5 millions citizens, France ) there is only like 5 or 10 fullstack job offers, and among those, maybe only 3 or 4 were I could be interested.
Even if Im a fullstack god, the only way to start would be to pick only "front-end" which sucks for fullstack god, work at home on their back-end every night, every week-end, and finally get the job I have the skills for. Why nobody told me the truth before ?
If you don't want to be beaten to death with a mechanical keyboard, then just do the code review remotely...?
I really like the thumbnail but I wish the "Junior developer" on the right would've worn a different hoodie
You forgot to say that everybody is allowed to learn and that making misstakes is a natural part of the learning process 😄
Making misstakes isn't too bad, at least if you aren't developing a "software as hardware" mess such that the code stays flexible to make adjustments 😂😂😂
Just fire any incompetent junior. A job is not a bootcamp. There is a nice talent pool out there.
While it'd true that Meta, and twitter programmers are out in the job market now, I don't know if firing people is the right way to grow the industry as a whole. Sure it's probably better to hire good engineers, but when you hire juniors you're not getting top level programmers.
Define the incompetence that you mentioned thus add value to your comment please, otherwise it sounds very shallow and worthless.
A workplace that wants to retain its employees needs to help them grow. Hell, some of the best engineers I know started as (paid) interning college students that were given job offers on graduation.
Lol, must be nice to be able to fire anyone. Most people can be taught almost any job its just juniors who usually have bad seniors.
If you think so, go ahead. You'll probably quickly earn a reputation for a toxic work environment in said talent pool.
I believe that a good feedback culture and psychological safety boost employee loyalty and lead to more success in the long term. Actually, if anyone knows about studies of such correlations, I would be very interested.