I liked this article and how it was framed for businesses but it seems generally useful to many different types of activities: - Pull requests should usually o

I liked this article and how it was framed for businesses but it seems generally useful to many different types of activities: - Pull requests should usually optimize for latency, not throughput (i.e. smaller PRs/changes are usually better) - Release frequently instead of infrequently (implying that frequent releases will be smaller but in frequent releases will be very large) - Non-strictness (latency-optimized) is more composable than strictness (throughput-optimized) ... this orbits another mental model I was exposed to a few years ago I call "weak-signal thinking".