Ship/Show/Ask - A Branching Strategy for Modern Dev Teams w/ Author & Eng Leader Rouan Wilsenach

**Rouan Wilsenach** (0:00)
The thing that we want to get better at as engineers is making changes safely, and branching strategy is one component of being able to make changes safely.
And so I think as teams, we should all be talking about how do we get to making changes safely, and if a change in your branching strategy comes out of that, then that's great if that's what your team needs. But I think that conversation about how do we make changes safely and still get going, that's the conversation to have.

**SPEAKER_2** (0:26)
Want to know how the world's smartest engineers are proving their dev team's connection to the business bottom line, or how they keep a lead cycle time while minimizing dev burnout and maximizing retention? These are just two of the topics leaders from Slack, Shopify, and Stripe will tackle at Interact on October 25th. A free, virtual, community-driven engineering leadership conference, Interact is a one-day event with more than 25 of the most respected minds in software engineering, all selected by the thousands of engineering leaders in the Dev Interrupted community. If you are a developer, team lead, VP, or CTO looking to improve your team, this is the conference for you.
Go to devinterrupted.com/interact to register free today.

**Dan Lines** (1:08)
Hey, what's up everyone? Welcome to Dev Interrupted. I'm your host Dan Lines, and today I'm joined by Rouan Wilsenach, a software engineer and technical leader.
Rouan, welcome to the show.

**Rouan Wilsenach** (1:22)
Thanks. Thanks for having me.

**Dan Lines** (1:24)
Awesome to have you here. I know you have a proven track record of helping build outstanding engineering teams, making amazing products. You've worked in tech stacks for companies in the financial services, education, leisure, and energy sectors, so like a bunch of different types of businesses, but it was actually your passion for writing. You wrote something really freaking cool that caught my personal attention. You published an article on Martin Fowler's website titled Ship Show Ask, A Modern Branching Strategy.
And man, yeah, I'm totally a fan of that. I don't read too many things and actually get excited about them. This I read and I was like, I gotta reach out to this guy. This is really cool. And it's a really cool take on how teams could be working.
And also, it's a little passion of mine and the work that we're doing at LinearB. So I wanted to first say thank you for the inspiration and getting out there and writing.

**Rouan Wilsenach** (2:35)
Sure, it's a pleasure. I like it so.

**Dan Lines** (2:38)
Are you writing a bunch of stuff or is it just this one or you're doing a bunch of written stuff too?

**Rouan Wilsenach** (2:44)
Yeah, I try to write whenever I can. So I find that it's something that I like doing. And I've written for a few different places in the past.
For me, writing is a good way of getting stuff down that people ask you all the time. So I feel like if I'm explaining something to different people multiple times, then writing an article is a good way of summing it up and having something to point to.

**Dan Lines** (3:08)
Yeah, it's a great point. I always try to make a point to say this to developers or engineering leaders out there.
Don't be afraid to write stuff down. Put it out there and you gave a good tip. If you are hearing people ask you the same stuff over and over again, it probably means that there's thousands of people thinking the same thing. So get your stuff out there.
And to kind of kick us off, where we're going to go with this pod, we're going to start with, I love these titles that our producers write for us, The Road to Ship Show Ask. So let's define Ship Show Ask. Can you give us a quick overview of what this is?

**Rouan Wilsenach** (3:49)
Yeah, sure. So basically, Ship Show Ask is, I call it a modern branching strategy. Maybe that's just me grabbing attention.
But I think essentially what it is, is it's me trying to describe a middle ground between continuous, maybe a spectrum rather than a middle ground, between your classic continuous integration and what we see at lots of organizations today, which is a workflow that's heavy on pull requests with lots of branching and lots of stopping points. And I think that we're at a point now where we can look at the way that we develop software and we can figure out where in the spectrum we are for every particular change that we're making and make the responsible choice. And we should trust people to do that.