Whenever we experience a problem in production
the usual intervention I observe is introducing more gates on the way to production.
»the usual intervention I observe is introducing more gates on the way to production.
»if they aren’t continuously coaching others on what they know, accelerating knowledge sharing, and helping the whole team speed up.
»is the reduction of the median rate of change across code elements (methods/classes).
»is non-linear in nature, with some exponentiality in it.
»then the refactoring step you plan to do is probably already too big.
»It’s close to impossible to measure good, testable design, but over the years two interesting metrics settled in my mind that are a fairly good indication of the presence of clear, explicit code that speaks the domain:
»that “pressure from product and business made us produce this mess in the code” I need to see how tight your feedback loops are.
»Some of the things I think about when asked how to influence change in teams/orgs as a Principal/Staff engineer:
than working on an isolated, long-lived feature branch, with a delayed review, integration feedback, and a lack of tests.
»If you halve the change size, your deployment frequency goes up twice, and now in order to keep the same change failure rate % as before you have to have twice as many failures per change.
»