Dragan Stepanović

…which decreases transaction cost, which enables even smaller batches, which means (even more) co-creation.

What if we shift thinking from
“everyone focus on finishing what they’re doing”
to
“everyone helping each other finish what they’re doing”?

I see people having to beg others to review their PR.

I tend to advocate for very small SUTs when (unit) testing (a.k.a. micro-tests).

The slower the test suite, the less often we’ll run it, the more we’ll backtrack whenever we make a wrong turn in the code, the slower we’ll go at the end.

Up until this point I was thinking that tests, as a safety net, help us to extend MTBF of the system. Just figured out that they actually help us with MTTR. But a different kind.

“To achieve wealth optimize for minimizing losses over maximizing gains”

Try building quality in by shifting left on the collaboration. Instead of mobbing on the outage, mob during the development. Diversity of thoughts, needed skills and system understanding builds the quality in.

With every halving of the PR size, you get 2x more interruptions for each of the reviewers of a given PR. Multiply that by the number of PRs in flight (one person, one PR) and you get the total number of interruptions in the team.
E.g. if it’s mandatory for at least one person to review a PR and if you have 4 developers in a team, total number of interruptions in the team increases 8 times (4x2). Just for one halving of the PR!

The problem is the engineering culture lacking design, refactoring, and incremental development skills that produced it as an artifact.