3 ms·
The goal of a code review should be to establish shared ownership. If that is valuable to your engineering org or team, then code reviews are valuable. Often te
by dcow 4y ago
The goal of a code review should be to establish shared ownership. If that is valuable to your engineering org or team, then code reviews are valuable. Often teams don't have the time or discipline to treat reviews that way, in which case they are not valuable (or negatively valuable because they waste engineering bandwidth). A practice that I've seen work well is for the engineer writing the code or the team in general to have enough situational awareness to realize when something really would benefit from having immediate shared ownership vs when something doesn't and the responsibility falling on the code author or otherwise team to determine which pieces of work should be more thoroughly reviewed.
- AnimalMuppet 4y agoOne of the goals of a code review should be to establish shared ownership (or at least shared-semi-competence). But code reviews have at least one other way of contributing value. They help find (moderately) obvious bugs, unsafe code, and unclear code. There is value in keeping blatant stupidity out of your codebase.
- dcow 4y agoThose are 2nd order benefits derived from establishing shared ownership.
- AnimalMuppet 4y agoThat statement is false. If I call your code, I don't have to share ownership of your code to benefit from your code not having a bug in it.
- dcow 4y agoThat’s not what I said. I said you get the second order benefits by establishing shared ownership. Of course the qualities of the code are conferred to callers… that’s obvious.