@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.
@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.
@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
@mhassam45
You are right I am already applying this the only thing I hate is my team lead he just not not approve PR but instead request changes for maybe small typo mistakes which really make me feel bad
@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. 😍😍
@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 😅♥
@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!
@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.
@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.
@whoizNiKHiL
is there any guide for all the best practices for the whole software development life cycle. I would love to have a central cheatsheet for that.
@CodingNuggets
I have to start submitting my code more. Thanks for hitting on this topic. Always useful information. See you soon!
@jasonhoman6525
How do you get a small PR if the ticket you’re working on requires a lot of change? Multiple PRs per ticket or smaller tickets and associated tasks?
@krzysztofk.8842
Omg, I did not expect to agree with you ;) spot on man !
@jonathancampos6009
I am going to a coding Bootcamp! I look up to you Clement!
@Tony198586
Clem, can you make a video to share your exp with your first Google interview on system design part? I think it's not too hard to study for the algo and data structure in 3 months, but system design seems a lot harder.
@vikrantkumar-brace
"what's up everybody how's it going" 🔥
@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🙏
@jcollins519