As a developer, I want my PRs to actually be reviewed by my coworkers and to have issues caught as a second layer of defense, etc.
As a reviewer, I effectively stopped approving things I couldn't give at least a cursory, reasonable glance (and tried to encourage others to follow suit because if we're not reviewing things, why not just push directly to main).
As a consequence, I have:
* tried to review most things within like half an hour of their announcement
in the shared MR channel
* requested a pair programming session and offered to do a pair programming
session for any large and semi-or-fully automated refactoring session,
like running a linter or doing a multi-file variable rename
(the pair programmer immediately comments on and approves the MR when it
appears)
* tried to limit my PRs to approximately 400 lines (not a rigid rule)
There were some specific instances of people not liking the "you must pair program if you're going to touch 400 files in one PR" requirement; but otherwise, I would like to think those on my team liked the more regular PRs, more people doing the PRs, etc, that resulted from this and some healthy culture changes.
I would also like to feel like the more junior devs were more willing to say anything at all in the PRs because they could follow the change.
I’ve seen this and variations done by teams to implement the metric. Usually, the “biggest” friction comes from “how do we know a PR needs to be reviewed within the time frame?” To which I always want to answer: “you have a mouth, put noises through it.” Sigh, sometimes I miss the military… anyway, toxic behavior aside, this is usually the biggest thing. I have to remind them that they go get coffee or smoke at least every hour, but rarely at the same time; so maybe then might be a good time to just do a quick check for an open PR. Or turn on notifications. Or if it’s urgent, mention it in the dev team channel.
But yeah, it’s hard to get the culture rolling if it isn’t already in place nor has anyone in the company worked with a culture like that.
As a developer, I want my PRs to actually be reviewed by my coworkers and to have issues caught as a second layer of defense, etc.
As a reviewer, I effectively stopped approving things I couldn't give at least a cursory, reasonable glance (and tried to encourage others to follow suit because if we're not reviewing things, why not just push directly to main).
As a consequence, I have:
There were some specific instances of people not liking the "you must pair program if you're going to touch 400 files in one PR" requirement; but otherwise, I would like to think those on my team liked the more regular PRs, more people doing the PRs, etc, that resulted from this and some healthy culture changes.I would also like to feel like the more junior devs were more willing to say anything at all in the PRs because they could follow the change.