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%.
»When it comes to the way of working, there's one small difference that can make a huge impact on your teams and organization
With Pull Requests you see just a polished and thought-through end result.
»Do you need to measure wait times and flow efficiency
if everyone that is needed is immediately available to respond (by #mobprogramming for example)?
»