“So then the changes in progress are just there, ready to go.”
“How are they copied? A network sync, an on-disk copy? What about conflict resolution?”
“The data is available on disk and yeah, there’s a sync. Conflicts happen less often than you might think.”
“That’s not how computers work!”
That’s what excitement colliding with worn-in assumptions sounds like.
“So the developer finishes their branch, opens a PR, and then merges it immediately. Once they get feedback, they’ll address it along with whatever they’re working on next. Or a follow-up PR, if they’re working in a different area.”
“But what about foot-guns and project style and crucial but subtle feedback?”
“Yeah, sometimes we shoot ourselves in the foot. But most people only do it a few times before they start to work through it. The upside of getting code into production within minutes instead of hours or days is worth it.”
“You release un-reviewed code within hours of writing it? Multiple times per day? That can’t possibly work!”
Whenever you hear about another team doing something strange that you can’t even process at first, you’re glimpsing a team’s culture peaking through the white space. The more unfathomable or shocking, the deeper the assumption you’re pulling on. Team culture is repetition, that which is done without even thinking about it.
Assumptions seem like an immovable object, until they’re not.
When you hear about practices that rely on none of those habits and assumptions, it brings the whole thing into question. Of course, your initial emotional reactions are “that can’t possibly work” and “why would you even want to do that?”.
Right after “that can’t even” is probably a pretty big insight. If you’re up for it.