> why they added that piece of logic in that file instead of further downstream This is the kind of thing that has always bothered me about code reviews. I'm c

> why they added that piece of logic in that file instead of further downstream This is the kind of thing that has always bothered me about code reviews. I'm confident that my teammates can write working code or any (obvious) bugs can be caught through code review, but is it possible there is a better solution by modifying code somewhere else? For example, there's a bug that is causing several issues, and there is a report for one of those issues. A patch is submitted to fix the issue without fixing the root cause and you're reviewing it. You verify the code looks good and that the issue is fixed - not knowing that the root cause itself is not fixed due to unfamiliarity with the system and it not being anywhere in the patch - and approve it. How much time should be spent looking at whats not in the patch for alternate solutions? How would I know if something could be updated "downstream"? Personally, I used to do it but not so much anymore.