>when one has been looking through the code for a while, they can miss things that will immediately stand out to someone else who hasn't looked at the code recently.
I agree with you, but it would seem rare. Maybe 1 out of 50 code reviews.
>For example, we had one developer on our team add a item to a JSON config file list and, since it was thought to be trivial, it didn't go through review. It turns out that they forgot to add a comma to the end of the quoted string. When it was time to roll out the change, we discovered the issue.
I would think in this example, the developer didn't bother to test his own code and he is using the code review as a replacement for that, which seems lazy. I would imagine the config error would pop up when he was running the application and that the config line he wrote was directly used by his changes. It would certainly pop up during QA.
I agree, but sometimes, when one has been looking through the code for a while, they can miss things that will immediately stand out to someone else who hasn't looked at the code recently.
For example, we had one developer on our team add a item to a JSON config file list and, since it was thought to be trivial, it didn't go through review. It turns out that they forgot to add a comma to the end of the quoted string. When it was time to roll out the change, we discovered the issue.
We have since enabled post-push linting on that repo, but I think that had someone else looked over it, they may have spotted that issue before it was merged.
> Again, what you are saying is right, but I believe you get decreasing values over time as the developer starts to "get" how the org wants things done.
To some extent, you're correct, but only if the code base is relatively static and conventions don't change. That usually doesn't hold true over time.