@jcollins519

I'd love to see a video of reviewing actual [bad] code. It would be good to see your philosophy on what is acceptable for the code in the context of future maintainability and how nitpicky you find it acceptable to be with the finer details. I find myself torn as to whether I need to be so strict as to comment on things as small as poor variable and component names.

@atifadib

I think learn more while reviewing code compared to writing code. Over the years, i have realised reading code efficiently is one of the most important skills as a SWE.

@skan90

Thank you, that helped me a lot! I've just started in the career as intern about two months and now all of us are making improvements and changes in a code written by the interns of the last year. And now it's the first time I get to peer-review code, so it's awesome to have insights of a more experienced person like yourself, about the manners to approach other team mattes.

@janehoe531

No one:
Absolutely no one:
Clement: btw if you're prep..
Everyone: here we go again

@ibrahimadam926

"What's up everybody how's it going " i love that saund 😅♥

@vikrantkumar-brace

"what's up everybody how's it going" 🔥

@MaximilianBerkmann

There are some good tips, there are two more I think that are too important to not mention:
- as a reviewer, you should make sure to review the code and not that X wrote something (i.e. making the review about the code and not personal to the PR/MR author).
- as PR/MR author, you should make sure to check if it's ready for review (is it set in draft/WIP mode? Do the preliminary checks passes like linters, formatters, tests, commit convention respected, ...).

@Agent_Ax

THUMBNAIL IS EXTREMELY OP

@tubeincompetence

I didn't see my favorite code review method mentioned here. "Close eyes and click approve". Usually works great! (until it doesn't).

And more seriously. Good video and feels mostly like what I am doing already. Some new features can be quite big though and I should probably split them up more. Often leave suggestions that PR author can decide to act upon or not. Usually approve when I either think it's all good or when I am quite sure the last small comments will be fixed before the merge. Tell it needs more work if there are more direct bugs or part of the PR that seems to be completely missing. And reject for when the PR might solve something else than it should or problem has been solved somewhere else already.

@krzysztofk.8842

Omg, I did not expect to agree with you ;) spot on man !

@CodingNuggets

I have to start submitting my code more. Thanks for hitting on this topic. Always useful information. See you soon!

@codispatch6869

Hi Clem, very good & useful video. Quick question - how much specific / detailed review of the PR needs to be done in general ?? Is there any good practice to follow for this ?? Thank you🙏

@jakariasami

I just realized that you didn't ever do any "live" on your channel. You have a large audience now. If you get time I would love to watch you live. 😍😍

@jonathancampos6009

I am going to a coding Bootcamp! I look up to you Clement!

@RisalHidayat

Very useful tips, Thanks Clément!!

@samuelbird4587

Hi dude. As a person preparing for an interview for a first software engineering job I just wanted to say thank you, because your videos are amazing. Not only do you help with understanding concepts like this, but also you're making me feel more comfortable about the interview and talking about these things. Love your work!

@talfromtelaviv

Great talk !

@mike24789

I think debugging is a great topic to cover. I’m really bad at it and I think it’s holding back my development as a software engineer. I could be stuck on a bug for a week and a more senior engineer can look at it and figure it out in 5 hours.

@molo3436

The best content of the internet🔥🔥

@sabapachulia

great video!