It's not about sharing the same database that's a problem
One more in “it’s not about X. It’s about about Y” series.
»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.
»And this is a short story about the process that penalizes people for trying to do their best.
»Interestingly, I noticed that the smaller the steps I take when refactoring, the less of a need I have to run the tests.
»Remember the last time you faced a big failure. How difficult was it to acknowledge it and how long did that process take? As you know, sometimes we can go whole life without being willing or ready to face it.
»