"Why is the specific id excluded?" is exactly the kind of thing we can capture in code, and that a good code review will flag.
It takes two seconds to write `EVIL_IDS_THAT_STOLE_OUR_LUNCH_MONEY=[1] [...] NOT IN EVIL_IDS_THAT_STOLE_OUR_LUNCH_MONEY` instead of `NOT IN [1]` and then not hate your past self six months from now when you have to figure out why something has been excluded.
If some code can't be understood today, it's not going to be able to be understood when someone comes to modify it. Maybe in your domain all the code is write-once-read-never, but for those of us maintaining enterprise software that isn't an option.
We absolutely expect our reviewers to fully understand the code. If you want a quick shortcut to make that cultural change, have any bugs in code go to the code reviewer instead of the original author. You will find people start taking code reviews a whole lot more seriously.
> We absolutely expect our reviewers to fully understand the code.
I suspect you don’t work as a DE or your company has top notch culture. I have never worked in any companies (including some big ones) that encourage a full understanding of any code submitted to PR review.
more or less the entire point of code review is to ensure that the reviewer fully understands the code that they review
i know that lots of orgs don't do it this way, but it's really important to make this point very clear: those orgs are wrong, and pathological, no matter how many of them there are
I want to agree with you. But I'd argue that for some career paths it is just impossible, and it is definitely impossible for my company. That's why I never consider myself as an engineer -- and I'm fine with it, because I don't love what I do. I take my side projects more engineer-ish.