3 ms·

> looking at a PR by a dev who has been around for a long time This is precisely the case where I think you need code review the most, because in my experience

> looking at a PR by a dev who has been around for a long time This is precisely the case where I think you need code review the most, because in my experience, time makes people complacent. Code review is peer review, the key agent of the scientific method. I just can’t abide a process that doesn’t include peer review. > Donald Rumsfeld's unknown-unknowns. are an excellent reason to have others question your code. Code review is a culture issue. If you have people who are so unfamiliar with code as to not be able to review it, then that’s a clear knowledge silo that seems perfectly addressable by _code review_. It’s not about the code, it’s about the knowledge transfer and peer enforcement.

incrudible 4y ago
> Code review is peer review, the key agent of the scientific method. I just can’t abide a process that doesn’t include peer review. The key agent of the scientific method is making predictions and comparing them to reality. In other words, you should test if your code actually does what it should do. If so, peer review does not necessarily offer any net benefit. If you absolutely insist on code review, then you do not belong on the team I am envisioning, which is totally fine. Like I said, the approach has obvious risks, but that is often a tradeoff worth making.
lamontcg 4y ago
Well, as someone who had a decade of experience with the codebase I absolutely submitted PRs which were largely unreviewable because nobody else had that level of experience. My safety net wasn't code review it was writing tests, and actually firing up the product and determining that it worked (which a large amount of people actually never bother doing, and I'd prefer that over code review any day). In those cases we'd do some knowledge transfer, but I can't turn someone into a veteran with decades of experience in an hour or two of code review. I'd actually be happy to do a week of knowledge transfer on the issue and treat it like a PhD dissertation defense (which is about what they were sometimes), but nobody else would want to commit that kind of time, and no manager would want to commit the team to that kind of time. And for knowledge transfer what usually works better is having more junior members of the team doing work on subsystems and guiding them through it. Even if it isn't peer review or pair programming, the iterative process of them hitting walls and asking questions is generally the best learning. That works better because they go off and commit the time to struggling with the problem, and then guidance has that platform to build on top of. And you don't understand unknown-unknows... You can't address that by code review or knowledge transfer or peer enforcement, because it is all the absolute unknowns. A healthy skepticism can help prevent risky changes, but at some point the bugs that get through are often completely out of left field that literally nobody could have foreseen. There is no perfect process that can prevent those kinds of defects.

incrudible 4y ago

> Code review is peer review, the key agent of the scientific method. I just can’t abide a process that doesn’t include peer review. The key agent of the scientific method is making predictions and comparing them to reality. In other words, you should test if your code actually does what it should do. If so, peer review does not necessarily offer any net benefit. If you absolutely insist on code review, then you do not belong on the team I am envisioning, which is totally fine. Like I said, the approach has obvious risks, but that is often a tradeoff worth making.

lamontcg 4y ago

Well, as someone who had a decade of experience with the codebase I absolutely submitted PRs which were largely unreviewable because nobody else had that level of experience. My safety net wasn't code review it was writing tests, and actually firing up the product and determining that it worked (which a large amount of people actually never bother doing, and I'd prefer that over code review any day). In those cases we'd do some knowledge transfer, but I can't turn someone into a veteran with decades of experience in an hour or two of code review. I'd actually be happy to do a week of knowledge transfer on the issue and treat it like a PhD dissertation defense (which is about what they were sometimes), but nobody else would want to commit that kind of time, and no manager would want to commit the team to that kind of time. And for knowledge transfer what usually works better is having more junior members of the team doing work on subsystems and guiding them through it. Even if it isn't peer review or pair programming, the iterative process of them hitting walls and asking questions is generally the best learning. That works better because they go off and commit the time to struggling with the problem, and then guidance has that platform to build on top of. And you don't understand unknown-unknows... You can't address that by code review or knowledge transfer or peer enforcement, because it is all the absolute unknowns. A healthy skepticism can help prevent risky changes, but at some point the bugs that get through are often completely out of left field that literally nobody could have foreseen. There is no perfect process that can prevent those kinds of defects.