Two parallel universes
When it comes to PRs and code reviews, if you are optimizing for these metrics in order to improved the process (and I believe you should)
»Enable then nudge
If you reduce the transaction cost in the system but don’t see a follow-through behavior of reducing the batch size, consider ways of, even artificially, increasing the holding cost in order to incentivize that batch size reduction.
»Separate refactoring tasks and PRs
I noticed that teams that use a process that makes reviews expensive (PRs and async code reviews are one of those) also tend to have refactoring as a separate task or a separate PR.
»A very different set of questions get asked
when people have a chance to get immediate answers compared to when there’s a delay involved. And the difference are the questions that enable curiosity, building relationships, and trust.
»Using Dummy objects in tests is a sign of low cohesion in production code
Over the years, I came to realize that usage of some test doubles and popular patterns in test code can actually be an indication of a deeper design problem in production code.
»If you don't feel the pain of delayed feedback with async code reviews
chances are you’re used to making big changes.
»It's about the mindset, not the tool!
Sure, until you realize that the tool is influencing the mindset as much as the mindset is influencing the choice of the tool.
»One alternative to using estimates for prioritizing work
is to invest in making experimenting and trying out ideas cheaper in order to sooner bring relevant data that can inform our decisions and reduce uncertainty as to what to prioritize and where to invest.
»Estimating effort in a fully loaded system
is a poor man’s try of achieving predictability while eroding trust and jeopardizing psychological safety.
»If it takes me 5 minutes to rename a method
and 1 hour to get a review and PR approval, that means the wait to processing time ratio is 60/5=12, and flow efficiency is only 7.7%.
»