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)
»in the first place is an environment without psychological safety.
»small enough for which the flow efficiency is terrible.
»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)
»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.
»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.
»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.
»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.
»chances are you’re used to making big changes.
»Sure, until you realize that the tool is influencing the mindset as much as the mindset is influencing the choice of the tool.
»