If getting feedback is cheap
it gets invited more often, which means it becomes more timely, which means it’s both more likely to be incorporated and that incorporating it is also cheap.
»If you feel the urge
to write that “How to conduct humane code reviews” document, there’s something deeper wrong with a given way of working and its inherent incentive structure than the lack of that document.
»Add enough integration and e2e tests
and the frequency of running them becomes approximate to not running them at all. Meaning, as if you don’t have them at all.
»The biggest problem with async work
When it comes to flow, the biggest problem inherent to systems based on async work is that they make the cost of starting new work effectively zero (the other side doesn’t have to be available in order to start new work)
»An environment where people have no ways of exercising vulnerability
in the first place is an environment without psychological safety.
»For any type of async work, I can always find you a batch size
small enough for which the flow efficiency is terrible.
»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.
»