Dragan Stepanović

processing time will get shorter as well because the feedback gets incorporated faster.

Shift in “outcomes over outputs” takes away power from people that used to have monopoly on defining solutions and next steps.

is (most probably) caused by:

One more in “it’s not about X. It’s about about Y” series.

It’s not about long-lived branches per se that’s an anti-pattern. It’s about coding in isolation for too long without getting the feedback.

Maybe late to the party, but just realized an interesting interplay between Event Sourcing and ever cheaper storage space.

Here’s a brain dump of thoughts I kept in my head about timeouts in distributed systems.

Being expressive about the domain doesn’t only improve readability, but also reduces coupling, which in turn enables incremental refactoring.

Here’s an interesting experiment.
Pick an existing Pull Request for a feature that was merged. Give that feature to the PR reviewer and author and asked them to do it again but pair this time. Count the number of words, sentences or comments they have on that work/code and compare it to the number of words/sentences/comments on the PR. Would you expect that results you got from pairing are the same as when employing PRs? Of course not. I expect results for pairing to be multifold higher than PRs. And that’s where you’re loosing most of your quality. With each and every PR. And I bet you’re chasing that quality afterwards in production which slows you way down.

What if senior developers were not allowed to write a single line of code alone? Instead, all the code and ideas have to go through the hands of less experienced developers during pairing/mobbing sessions.