5 ms·

Whoever OKs a code review can be called upon at any moment to explain the logic of the change in front of the team. If you OKed it, you must understand it, righ

by z5h 8y ago

Whoever OKs a code review can be called upon at any moment to explain the logic of the change in front of the team. If you OKed it, you must understand it, right? If no one is willing to accept a PR with that provision, the author needs to make their code clearer. In my experience, people doing a code review don't want to bruise their egos by saying "I don't understand this.". So they superficially check the code and OK it.

maybeiambatman 8y ago
Definitely guilty of this :(
DogLover_ 8y ago
I would question if that approach is appropriate. It will lead to less releases with bugs but will also lead to lower velocity. Lower velocity can have the effect that in the long term the system is in a worse place than if it had more iterations of work. As many things, it depends on the company and the industry it is in.
Benjammer 8y ago
There are also places where the incentives just are not there for in depth code reviewing. You could work in a culture where you are literally hurting a junior's chances of promotion by being tough on their code and asking for changes, because their peer on another team is getting twice as many tickets "done" because his team just "rubber stamps" LGTM on everything. Many teams would never actually put in the effort to trace issues back to individual failures in a code review process, when they could be spending the time just fixing the problem and moving forward.
Benjammer 8y ago
Sorry for the double post, I had another thought here. The value trade-off you're suggesting is that the time and effort required to set up this process structure, and shift everyone's work habits over to this, is worth it in... maintenance?... at some point? Reduced risk of some sort? This seems like a complicated position to argue, can you be any more specific about where and how you see this type of exacting process adding business value?

by z5h 8y ago

maybeiambatman 8y ago

Definitely guilty of this :(

DogLover_ 8y ago

I would question if that approach is appropriate. It will lead to less releases with bugs but will also lead to lower velocity. Lower velocity can have the effect that in the long term the system is in a worse place than if it had more iterations of work. As many things, it depends on the company and the industry it is in.

Benjammer 8y ago

There are also places where the incentives just are not there for in depth code reviewing. You could work in a culture where you are literally hurting a junior's chances of promotion by being tough on their code and asking for changes, because their peer on another team is getting twice as many tickets "done" because his team just "rubber stamps" LGTM on everything. Many teams would never actually put in the effort to trace issues back to individual failures in a code review process, when they could be spending the time just fixing the problem and moving forward.

Benjammer 8y ago

Sorry for the double post, I had another thought here. The value trade-off you're suggesting is that the time and effort required to set up this process structure, and shift everyone's work habits over to this, is worth it in... maintenance?... at some point? Reduced risk of some sort? This seems like a complicated position to argue, can you be any more specific about where and how you see this type of exacting process adding business value?