I like the notion but I tend to think about this as a social problem rather than a personal problem. I.E it’s more about how the team collaborates than how each individual behaves. And also about incentive structures that support that behaviour (which then makes it not just about the team but about what’s around the team). In my experience we don’t get good at CI until we create highly collaborative teams with incentives driving that collaboration. But using this we can get better.
I agree, it's a combination of both. I do personally have an issue with reviewing big PRs, I tend to procrastinate. Assuming positive intent, my colleagues also tried their best to make it small but it is still large.
In your experience, how would you provide an incentive to reviewers to push through and not procrastinate? I find that hard without forming an "anti-identity" or "anti-goal".
We have structures around it, for example, we look at what's in review during stand-up and agree to prioritise that as a team after stand-up - then we still miss it because of that overwhelming feeling.
I think the problem is created earlier in the process. What would happen if your team focused on making sure PRs are never larger than 5 minutes of review time? How big would each task then become? What happens if you are not allowed to mix structure changes with behaviour changes? Would that allow you to either shrink the PR size, or perhaps use different workflows for each type? If the team has to work on something that would create a PR larger than 5 minutes review time, then perhaps you have to pair or mob to do it, removing the need for a PR.
That's an interesting thought experiment to measure PR by the length of review time! Shrinking or decomposition is ideal, my experience is task decomposition is a skill which will take a while for an engineer to learn, while that skill is being picked up, there'll always be a burden for the reviewers. There's also a limit to how much decomposition can be done upfront, which warrants another long-form thought.
Pairing and mobbing works, unfortunately, in some of my clients, we have timezone constraints.
I love the idea of not mixing structure/behaviour, I'm currently experimenting again with PR stacking which seems to be growing as an ecosystem (via git town) - but still having a lot of friction due to conflicts (GitHub squashed merge).
We’re experimenting with some of this stuff to see how we can minimise break in flow and I’m likely going to write about it when we’ve had some more experience from it. I’d love to see how you progress with your clients as well. It’s not easy and often not that generic. So hard to find really good advice or patterns.
I like the notion but I tend to think about this as a social problem rather than a personal problem. I.E it’s more about how the team collaborates than how each individual behaves. And also about incentive structures that support that behaviour (which then makes it not just about the team but about what’s around the team). In my experience we don’t get good at CI until we create highly collaborative teams with incentives driving that collaboration. But using this we can get better.
I agree, it's a combination of both. I do personally have an issue with reviewing big PRs, I tend to procrastinate. Assuming positive intent, my colleagues also tried their best to make it small but it is still large.
In your experience, how would you provide an incentive to reviewers to push through and not procrastinate? I find that hard without forming an "anti-identity" or "anti-goal".
We have structures around it, for example, we look at what's in review during stand-up and agree to prioritise that as a team after stand-up - then we still miss it because of that overwhelming feeling.
I think the problem is created earlier in the process. What would happen if your team focused on making sure PRs are never larger than 5 minutes of review time? How big would each task then become? What happens if you are not allowed to mix structure changes with behaviour changes? Would that allow you to either shrink the PR size, or perhaps use different workflows for each type? If the team has to work on something that would create a PR larger than 5 minutes review time, then perhaps you have to pair or mob to do it, removing the need for a PR.
That's an interesting thought experiment to measure PR by the length of review time! Shrinking or decomposition is ideal, my experience is task decomposition is a skill which will take a while for an engineer to learn, while that skill is being picked up, there'll always be a burden for the reviewers. There's also a limit to how much decomposition can be done upfront, which warrants another long-form thought.
Pairing and mobbing works, unfortunately, in some of my clients, we have timezone constraints.
I love the idea of not mixing structure/behaviour, I'm currently experimenting again with PR stacking which seems to be growing as an ecosystem (via git town) - but still having a lot of friction due to conflicts (GitHub squashed merge).
Work decomposition is a skill. I wrote something little about it the other week (http://tomasmalmsten.com/posts-output/2024-07-01-decomposing-work/). Perhaps it’ll help.
We’re experimenting with some of this stuff to see how we can minimise break in flow and I’m likely going to write about it when we’ve had some more experience from it. I’d love to see how you progress with your clients as well. It’s not easy and often not that generic. So hard to find really good advice or patterns.
Now, I have a new motto: Don't be a Production Blocker, be a Production Block Buster!
That would have been a better title for the post!
Thank you! Feel free to use it, I would be ecstatic if I see this one day on a resume.