13 tips to make your code reviewer NOT hate you

#neetcode #leetcode #python

[egor.okhterov]

One more reason to break your review into small atomic pieces is because of merge conflicts.
What increases the probability of merge conflict?
Two things:
1. Time your code spends in review stage.
2. Change surface area.

The larger the surface of your change, the higher chance for you to collide with someone else.

The bigger the review the longer it will be in the review stage and others have probably merged their code that conflicts with your change.

[thetruebluesingaporeankid]

Omg my senior eng showed down my fellow eng in front of the whole group for not reviewing code first

[kxmode]

I agree with making smaller changes. When they're isolated, it's easier for the reviewer to understand the context.

[egor.okhterov]

Automate easy stuff means unit tests and linters

[onlinealias]

I have a guy on my team that makes assumptions about what the code is doing during a pull request, and tends to start insulting people and saying they have “skill issues” when he doesn’t even know what he is talking about. It’s very frustrating.

[devinjohnson]

Thanks for the advice man! This will definitely help on my new job!

[SandraWantsCoke]

Always review your own code and when you do think of it as if you were reviewing somebody else's code. You will find a lot of things. Correct them and only then send it off for review. Else you run into too much back and forth where you have unused code, debugging logs, poor code etc. It's worth it.

[KosstAmojan]

I think "Narrowly scope changes" means "don't implement a fix in a scope that's higher than necessary for it to work." In other words: don't fix something by making it global in your code. Implement it at level of scope where only the the code that needs it has access to it.

[Amy-]

This is good. Also, my code 👩‍💻 had dependencies, so I would essentially include the people whose packages or base code I was using to create mine, in the review. At one company, they had engineers 🧑‍💻 across geographical locations, so if I included someone from a different geographical or international location, CR could take potentially a little bit longer! - Amy

[hellowill]

Write a clean description and even leave comments on things you think are weird (comes under "review your own code first" I guess).
I think the most important thing is understanding that code review is an important part of the job. My lead would often say in stand up all he did yesterday was review PRs and I thought that was quite powerful because the other guys were stressing about not writing enough LOC themselves, the team really changed after he said that.

[cryptonative]

The biggest one is write a description of what the code does and maybe the different subtasks, edge cases and quirks you found.

[zeeblo_dev]

love videos like this, really informative +1 sub
also 2:44 was hilarious 😂

[protodimbo]

I have to disagree with the point "Break your pr into small prs". Yeah, it's easier to review, but we have trunk based development for example. Where every pr should be consistent. You should have a perfectly working system after every pr. That said, sometimes it's almost impossible to split your task such ways (of course you can add a couple feature flags here and there). But I like to follow this rule - 1 task - 1 pr

[thetruebluesingaporeankid]

Use sub tickets!!! For large changes sun stories which really helps! But not everyone follows agile

[luigidipaolo]

11k out of those 12k added likes are probably there because you installed an icon package with pnpm

[thetruebluesingaporeankid]

But linking should have been set in the repo for the expectation

[egor.okhterov]

Treat your change as a product.
Every product has a beautiful package and marketing campaign.
You should market and sell your product to the fellow engineers.
Reading your review should be interesting, exciting and provide a learning experience.

Code usually have no comments and no documentation. This is not bad. This is how it should be.
Programmers learn the code base by reading git blame and finding the review through git commit history.
Your review in not a one time effort that will be thrown away after you merge.
Future programmers will learn the meta of the code through your review description and comments in your review. So put effort for the future programmers, give them an opportunity to learn the code by reading your change descriptions.

[bogdanivchenko]

why can't you make monthly neetcode subs?

[thetruebluesingaporeankid]

Formatting is till ok but not like you’re changing the whole ass file

[Alexander-gfxm]

This was some of the most vague shit I've ever read. You literally spent 80% of the video interpreting what he meant lol