in a way that it amplifies the pain that every single individual felt when working in isolation, but because everyone was suffering alone, the pain was perceived not as high to address it.
»contains more action items related to adding more gates before a change reaches customers, rather than reducing the size of the change, you’ll likely end up with having to create even more incidents reports.
»to what it wants to be, instead of you trying to force it into your idea of what it should be.
»is that once they persist long enough and are more adopted in the industry, they become familiar solutions.
»is not Balanced or Safe or Conservative Programming.
»with each deployment (smaller changes), not more delayed feedback (more gates, more branches, etc.).
»(same as with async code reviews) is that the author knows when and what kind of feedback they need.
»Sure, just be aware that your sense for determining “when it makes sense” was shaped by the opposite way of working (work in isolation) which likely optimizes for having hard time finding scenarios when pair/mob makes sense.
»(say that a simple, yet good enough proxy for that is halving the size of a PR, or halving the time taken to create a PR) but you don’t halve the wait time to review it, you’re losing throughput of number of changes you’re able to push through the system of work in a unit of time.
»is that the system doesn’t give a damn that you’re mad at it because you’re getting outcomes opposite to the ones you’d like to get.
»