Fireside Chat with Grandpa Paul

Matty: [00:00:01] I never remember which is the name of the organization and which is the name of the conference. Yeah, but it’s whatever pink something. It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton, and I have a great guest with me today. But first, a word from our sponsors. This episode is sponsored by VictorOps. Built for modern incident management, VictorOps provides a unified platform for real-time alerting, collaboration, and documentation. Driven by your IT and DevOps system data, VictorOps helps you to respond to incidents more effectively so you can minimize downtime and make being on call suck less. Visit arresteddevops.com/victorops to schedule a demo or start your trial. Mention you heard about VictorOps on Arrested DevOps, and you’ll be eligible for some sweet discounts too.

[00:01:03] GoCD is the on-premise open-source continuous delivery server created by ThoughtWorks. With GoCD’s comprehensive pipeline modeling, you can model complex workflows for multiple teams with ease. And GoCD’s value stream map lets you track a change from commit to deploy at a glance. GoCD’s real power is in the visibility it provides over your end-to-end workflow. So you get complete control of and visibility into your deployments across multiple teams. Say goodbye to deployment panic and hello to consistent, predictable deliveries. To learn more about GoCD, visit gocd.org/arrested to download. It’s completely free to use. Commercial support and enterprise add-ons, including disaster recovery, are available. This episode is brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 120 common infrastructure tools such as Chef, Docker, and AWS so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a free 14-day trial at arresteddevops.com/datadog.

[00:02:20] So today’s guest and I’ve been trying to record this episode for at least a year. Uh, we tried to do it last year. I forgot that the Monday we were going to do it was Labor Day. That got confusing. Uh, and then we actually sat down a couple weeks ago. We were out at a bar and said, this is when we’re doing it. We tried to record it yesterday and his internet went out. It was a whole thing. So we’re trying this again. So I’m really excited to have J. Paul Reid joining me today to talk about DevOps, release engineering, and pretty much whatever random things come to mind. And the show notes for this episode can be found at arresteddevops.com/grandpapaul.

Paul: Thank you for that intro, especially the Grandpa Paul part.

Matty: Grandpa Paul.

Paul: Yeah. Well, you know, you sit there on your DevOps porch and say, get off my containers.

Matty: Exactly. So, Paul, you want to let folks know a little bit about your background, kind of your DevOps history?

Paul: Yeah. Well, I started in release engineering. Build and release engineering is my background, and I’m a consultant. I started doing consulting about 5 or 6 years ago, actually. It’ll be next year. The way I explain it, I feel like DevOps is sort of what release engineering kind of became, or at least there’s definite threads of that. I kind of got pulled into the DevOps community that way. Then for those who may be wondering, this voice sounds a little familiar, we used to do a podcast called The Ship Show. That was a podcast that we did for a number of years, one of the earlier DevOps podcasts with DevOps Cafe and the Food Fight Show at the time. I had a number of wonderful co-hosts, and we did that for, what, 60 episodes, I think, is what we tried to do over, I don’t know, 2.5, 3 years. And so that was a lot of fun. But yeah, I’ve— it was funny. I was— we were talking about this, I guess, yesterday that somebody introduced me. I think it was All Day DevOps. They introduced me as a founding member of DevOps or something like that. I was like, no, no, no, no, I’m not really a founding member. I just happened to be around when a bunch of the early stuff was going on. And as a function of the podcast, got to cover a lot of early Velocity conferences, a lot of early Puppet and Chef comps. We got to cover the 5th anniversary of DevOps Days in Ghent. So, I was just really lucky and privileged to be around people that were there at the beginning. But I don’t know that I would consider— maybe a founding groupie.

Matty: [00:05:03] There you go. Yeah, you were tangential to the founders.

Paul: Yes.

Matty: Well, you were recording, like, who’s the guy in the Civil War that took the pictures? What’s his name?

Paul: I have no idea.

Matty: See, you know what’s funny? Okay, so again, so there was a whole thing. We recorded about 12 minutes yesterday and I was like, hey, we can just pick up where we left off. And Paul’s like, no, no, no, I want to say it again because it’ll be better. And so we’re going to be all fine. And now again, I drop another one in there where we have no idea what we’re talking about.

Paul: Hey, I’m fine. You’re the one talking about the person who pictures.

Matty: Yeah, there was a famous Civil War photographer who documented things. Or you’re the Christiane Amanpour of DevOps.

Paul: There you go.

Matty: So, yeah, The Ship Show was very formative to me. When I was starting to get involved with DevOps, I kind of absorbed everything through podcasts, and Ship Show was one of the first ones that I listened to. Again, we talked about this yesterday, so you get to hear about it again because you didn’t hear what we recorded. But one of the things I asked Paul was I was really curious about the opening theme because I thought it was really awesome, and I wondered if it was something that was bespoke because there’s a sound clip in there, where it says, what is your purpose in life? To ship, of course, right?

Paul: [00:06:22] Yeah, yeah.

Matty: And it reminded me very much of, uh, there’s this band from the ’80s, it’s called Information Society, and they had this song called Pure Energy, and it was the, I want to know what you’re thinking. And if you— I love the album, and like every song had like little sound clips from Star Trek and sounded just like that.

Paul: And yeah, yeah, the— so the song, let’s, let’s see if I can dig it up here. This song is actually from a group called, uh, Anti-Loop, and it’s called Purpose in Life. And, um, let’s Did I? Oh, there it is. You hear it? Yeah. Anyway, what we did is I actually stole that song from— oh, there it is. So it’s funny, actually, I edited that. The person says to explode, of course, but the original song comes from— I actually had to go look this up because it was actually kind kind of formative for me. There was a show called Does Humor Belong in Technology? Dibbit. And so dhbit.ca, you can go look at the really old episodes now because it was something— it was before podcasts really. And it was a group of people and they would get together and do this, you know, before podcasts. So they would stream it and they had an IRC channel. And so you would like get together on Sunday nights. This is we were nerdy, obviously, in college. You’d get together Sunday nights and listen to this Does Humor Belong in Technology? And they would just kind of— it was kind of like a morning show where they would just sit there and chat with each other, and they had this background music, and that was one of my favorite songs. So it’s by a group called Antiloop. But yeah, we edited— that’s actually me at a very sped-up rate saying, to ship, of course. And that’s where that song came from.

Matty: [00:08:13] But Our theme song, which I never think about because I only listen to the episodes before we edit them and I drop it in. But a friend of mine who now works in technology, which is funny because all the time I’ve known him, he knew nothing about tech. He’s a musician and a composer. But he did our song for us, which is very cool. His name is Brian Crane. And I’ve, you know, we don’t really attribute it because he didn’t actually ask us to do that. Even though I was like, do you want me to say a thing? And so this might be the first time we ever told anybody that Brian Crane Uh, as the person who did the Arrested DevOps theme. And the other thing, just real quick, and then we’ll get to like talking about DevOps and stuff other than just this dorky crap. Um, if I recall correctly, Paul, you are the genesis of there’s always DevOps in the banana stand, right?

Paul: Yeah. Well, or was it Nathan? Well, so here’s the thing is I, I think I do remember that there was a— so we had I think it was you and Trevor and Nathan Harvey and I had a Google Hangout back in the day. Yeah.

Matty: [00:09:21] When we were getting started, I asked the elder statesman of DevOps podcasting, I was like, hey—

Paul: The 2 grandpas.

Matty: Right. Can we jump on a Hangout and talk about how you do your shows and get some tips and stuff? I remember Nathan talked about how they jokingly at the end of the Ship Show, once or twice, he said, okay, chefs, keep it hot. And then it became this thing he had to say all the time. And then I think, Paul, you said, yeah, you could say there’s always DevOps in the banana stand.

Paul: Yeah, yeah, there was an Arrested Development riff there. And, and, um, yeah, we, we did that. That— so that was the Food Fight show sign-off. And then we did the, you know, from wherever you were, from whatever city, this is so-and-so signing off. Um, and that was our kind of signature thing. So yeah, I mean, it’s— I think it’s important to have, have good branding there. But, uh, DevOps in the banana stand’s pretty good. And hey, I’ll take credit up for it if you want me to.

Matty: I want to just say one thing and then bring into another topic too. The final kind of thing, thinking about podcasting, when you talked about doing the Ship Show and being able to talk to a lot of folks who were very formative in what was going on in those early days. So Brian Berry, who was one of the founding folks at Food Fight, he has a blog post called You Should Start a Technical Podcast. And in it, he mentions, he says, kind of the dirty little secret of tech podcasting is this is the way that you get people who you normally wouldn’t have the opportunity to sit and talk to for a length of time to spend an hour talking to you. And it’s absolutely true. I mean, that’s one of the most awesome things about doing this show is being able to sit and spend an hour talking to, you know, folks like James Turnbull or, you know, Charity Majors or, you know, Jez Humble or all sorts of other folks we’ve had on the show. Who it’s not like that at a conference they wouldn’t be nice and talk to you, but people are busy, right? Like you’re not going to be able to sit down and say, “Hey Patrick, let’s let’s sit down and spend an hour just chatting in the middle of a DevOps days.” You know, I mean everybody. Yeah, sweet.

Paul: [00:11:30] Yeah, yeah. No, we I got that a lot, and that’s something with the ship show. You probably experienced this too, where you’ll be at a conference and you’ll be talking to someone, and and for me it was always when I got very animated about something usually get. Talking about Git, but people would be like, I’ve heard that voice before. And I remember some of the other co-hosts mentioning that too. It’s like, oh, who, you know, who’s that? And then they rack their brains to figure out where, where they’ve heard it. And it’s like, all right. And then the other fun thing, I was like, listeners would tell us what they would do while listening to the podcast. And the big one was like yard work, like mowing the lawn. Like, okay, laundry was another— chores were a big one.

Matty: For me, it was the car because at the time—

Paul: The commute? Yeah.

Matty: Well, it wasn’t even the commute. It was that at the time before I moved closer to where my kids live, I was several times a week driving for almost an hour each way to go see my kids and everything. I was sitting on the Eisenhower Expressway listening to Ship Show and DevOps Cafe and just going through all of that. It’s funny. When you start to, you know, people that you, you quote unquote feel like you know because you listen to their show and then you get to know them in real life. But it’s like, I felt like I, you know, it’s sort of like, I feel like I know you even though we haven’t met yet, you know, kind of thing. And I know it’s funny when on the ADO side, I mean, I think Trevor probably makes the most hay out of his, his podcasting fame. He definitely gets into like people getting excited and wanting to do selfies and stuff like that. So we get a lot of that. By the way, we have an Instagram Um, if you go to instagram.com/arresteddevops. Yeah, I just, I just posted a picture of myself.

Paul: [00:13:12] Yeah.

Matty: Because, you know, when I—

Paul: we never did that. We— yeah, that’s one thing that I’ll give you props on. Sometimes you do like Hangouts that you stream or have video of, and it’s like, no, you didn’t. You, you wouldn’t want to see us taping.

Matty: Well, we’ve, we’ve kind of dropped that because it’s, it’s nice to have the control. But I mean, I think it’s hard.

Paul: It’s hard work.

Matty: It is. And, and for, for listeners who don’t know, I mean, Paul, this is probably why you kind of had to stop, because you put way more effort into Ship Show than, than, than we do. You know, I think you told me that it was like 5 minutes for every— of work for every 1 minute of—

Paul: it was more like a show. Yeah, yeah.

Matty: I mean, so you’re a lot more, uh, diligent about your post-production and stuff. But I, I think, I think we do a pretty good job of— oh, definitely releasing, releasing regularly and all that good stuff. But anyway, Anyway, let’s talk about some DevOps.

Paul: Let’s talk about some DevOps. Yeah. Nice little stroll, holiday stroll down memory lane.

Matty: [00:14:12] And it’s great. We can talk about podcasting junk because Bridget’s not on. Bridget gets really bored when we talk about the inside, like when we’re on the show talking about the behind the scenes part of it. It’s sort of like how Sasha would get when you guys would talk about source control.

Paul: Yeah. Or I feel like there’s a VH1. Is there a VH1 behind the DevOps or something?

Matty: Yeah. Well, you know what? Okay. And again, I swear to God, we’re going to stop talking about podcasting. But I super wanted well now we’re sort of doing it, but I super wanted to do an episode with like you and me and Nathan and Damon and John, and like to just talk about like what it’s like to do a DevOps podcast. And it’s it’s just funny. Like I was like ah no one want to listen to that blah blah blah. And I’m like well then they don’t have to listen to that episode. So guess what? We sort of just did that one for the last ten minutes. So.

Paul: We’ll do that.

Matty: We’ll do that in a couple years when we get sure the next time we can schedule something.

Paul: Yeah, although there was one, and I’ll I promise we’ll not we won’t talk about podcasts anymore. But that one there was what was the episode idea? Because didn’t you end up doing it with Nicole?

Matty: [00:15:16] That was like the car talk.

Paul: The car that’s right. That started on Twitter as a conversation between all of us. Uh, yeah, the Car Talk episode. I remember that.

Matty: Yeah, it was, uh, the, um, it was something because Nicole was talking about how people would say stuff to her and she— they’d be like, are you sure, Nicole? And she’s like, yeah, data. And I think you were saying that, you know, there should be a call— she should have a podcast called You Sure, Nicole? And then we kind of did this thing where it was, it was the DevOps call-in show. Where we got questions. And by the way, speaking of which, we’re going to try to do something similar for our 100th episode. Oh, nice. It’s an AMA for the host. So if you go to arresteddevops.com/ama, as in ask me anything, you can ask us questions you want us to answer on the show. That could be about DevOps, could be about the show, could be about what we do for work, or you could just tweet us. Hopefully we’ll do that. So anyway, but so one of the things that, that, uh, there’s a topic I want to talk to, but to lean into it, or to lead into it, the, the, the way I kind of first heard about this was a couple years ago, uh, Paul and I and, and a couple other folks were invited to, uh, speak at the, uh, Pink Conference, um, which is the, you know, big ITSM ITIL conference. And it was the first year they were having a DevOps track. It was really exciting to come and do that. And, uh, a lot of people that really needed to hear that message and were really interested. But one of the things that was cool for me is, uh, I guess they do this thing, and Paul, you can talk about it. They have this, uh, Pink Think Tank. So I guess the week before the conference, they got a bunch of, uh, you smart people, uh, including, uh, you know, Rob England, who’s the IT Skeptic on Twitter. And you guys came in and y’all came in and talked, you know, thought big thoughts and, and all that. And then I, I was, uh, fortunate enough to kind of see the presentation of what, what, what y’all thought about. And that’s when I first, uh, was exposed to, and I’m going to pronounce it wrong, but is the Cynefin, the Seinfeld framework?

Paul: [00:17:29] Yeah, we always laugh because Cynefin, right? No, it’s Cynefin. No, no, it’s Cynefin. But people see it. It’s a Welsh word. So the vowels and the consonants are all hard and soft in the wrong places, right? The hard C and the hard F. But anyway, yeah, the Cynefin, as we joke. And actually, Dave Snowden is the person who sort of came up with this sense-making framework, and his head will— he’s Welsh— his head will explode if you call it Cynophan. But yeah, so you mentioned Rob England at the Pink Conference. He does the Pink Think Tank every year, and he gets a bunch of people together. And one of the interesting things about it is that he keeps it sort of fresh by— you can— I don’t think he’s had any repeat think tankers, right? It’s always new people every year. I mean, he’s there everywhere every year, and he gets everybody in a room for a day and And they think about— there’s a leading question. We meet or we met a couple of times via Google Hangout, but not for long, mostly just to kind of think about the question beforehand. We get together, we think about it for a day before the conference, and then we put together a bunch of what we come up with. We had a bunch of— we had some whiteboards and stuff in there, so we took pictures of that, turned that into a presentation. It’s actually a couple presentations. Bob, as you mentioned, is the IT skeptic. That’s his big kind of brand thing. But it’s funny to see him change recently around DevOps. He’s really done a 180, and he’s sort of all in on DevOps. He was very skeptical at first. We did a think tank that was largely about IT problems and DevOps and that sort of thing. Damon actually joined me there, and then a bunch of other people. So we did a couple of reports and we brought up the Cynefin model. It came up, I brought it up, and one of the other couple other people brought it up as well as a way to sort of start looking at IT problems. What’s interesting about it is that it is starting to be— you start— if you ever hear a technical presentation where they use the word, the words chaotic, complex, and complicated, in close proximity to each other, as if they’re talking about a ladder of situations getting worse or something like that, you can bet that they’re talking about Cynefin, because that— those are kind of the main, you know, its main— if you call it a quadrant, again, Dave Snowden will bite your head off because it’s not a quadrant. But, but, you know, obvious, or they call it simple systems, complicated systems, complex, chaotic. That’s, that’s a model that you’re seeing being applied like all over the place. And not just, by the way, to IT. I mean, it was— it’s used to solve like international, you know, international politics problems, lots of different uses. And so it’s fairly interesting and it’s a good— it provides a good model to sort of think about a lot of the things because I think people talk about complex systems a lot of the time. But it provides a bit of a sort of framework or model to think about, well, what do we mean when we say complex system? What do we mean when we say complicated? How would we act differently in a complex situation versus a chaotic situation? And it gives us the language to really talk about those things, which I think is, is super important.

Matty: [00:21:07] Yeah, I mean, I think I’ll put a, put a link in the show notes to the Wikipedia article, but it goes into kind of that good explanation of you know, the idea of simple, obvious, right, which is the known knowns, you know, the complicated are those known unknowns and, and where those, those places go. And, and I think hopefully— I don’t remember if, uh, if the presentation from the think tank is publicly available or if it’s only for— if it is, we’ll, we’ll find a link to it.

Paul: Yeah, I’ll see if I can dig it up.

Matty: Sorry, not sorry.

Paul: Yeah, no. So, so one of the interesting things I think so, so I think where this comes up and I, and I get, I get sort of yelled at on Twitter about this often, which is fine. I kind of like complain about our use of best practice and really IT’s use of the term best practice. And that argument fundamentally comes from the Cynefin model because it argues or sets up and says that best practice is only applicable in simple or obvious systems. We don’t work in simple systems. We work at best in complicated systems, and usually in complex. We kind of straddle that boundary there. One of the presentations that I do called the 5 Dirty Words of CI, one of them is best practice. It doesn’t take a lot of examples to prove that best practice is not actually a thing in our industry that we should be so concerned with, because I just asked the question, how many people like their best practices and hands go up, and then how many people like other people’s best practices and then hands kind of go down. Or the other example I often give is you’ll just ask the team separately, hey, what’s your best practice for rebooting the database? Go ask the database team, right? But you ask that question separately of those people and you’ll get different answers. It’s like, well, if it’s a best practice, shouldn’t all your answers be the same? And people will then sit there and argue for why their best practice is better. And that is a great example of, no, you know, you don’t have best practice, you have good practice. There’s— yeah, and Ken Mugrake, uh, who is DevOps— he’s, he’s just joined the, the DevOps Days group, the international one.

Matty: [00:23:27] Yeah, the core team.

Paul: Yeah, the core team. He, he and I— and I, and I told him I would steal this from him. Um, he brought up the— this idea of, um, chosen practice, which I really liked because basically he was trying to make the distinction of best practice in our environment, in our company, in our context. He was saying that companies have what they call best practice, but it’s not industry best practice. It is good practice for us. It’s chosen practice. I really, really like that idea. To be honest, there was a presenter at the Pink Conference who was talking about best practice. I tweeted it, and I won’t tell you where they’re from, but they said they were talking about DevOps, and they were talking about how this is really great. I can’t even remember what aspect of DevOps they were talking about, but they were saying this is really great because this is industry best practice, and management loves that. It’s not some one-off thing that nobody else is doing. And I tweeted, oh, you mean a one-off thing like Amazon and Google and Netflix, right? And, and right. And so I just think, you know, like I said, it gives us good language to think about those things. And it, in some ways, I think explains— we all run around, you know, the best practice thing, we all run around talking about it, but we actually are doing good practice, or maybe you might call it chosen practice.

Matty: [00:25:03] I like chosen practice.

Paul: That’s great.

Matty: The term that, um, we, we’ve used at Chef is we talk about having, uh, patterns for success.

Paul: Yeah.

Matty: You know, with, with customers, because again, they’re patterns, right? Practice is like a thing that you do, right? Like we usually think like you do this thing, whereas a pattern is kind of a way of thinking about things, but the way you implement it is going to potentially be a little different. It’s like a little higher up the Right. And then how you make that happen is what’s going to be more specific to you. Right.

Paul: It’s this kind of idea of heuristics around what we’re doing is, you know, are we Netflix? Are we shipping videos across the internet? Does that context make sense? You know, one of the other examples I give about why best practice is not a thing is that in the complex and complicated space in which we work, this is also very intuitive to a lot of people. We literally can’t define everything. And we can’t come up with a defined procedure that takes us to the end. So the example that I give is, okay, the database goes down, or, you know, the web, you know, the web server goes down, whatever. And people will say, okay, well, get the runbook for that, right? And how many of our runbooks say, well, okay, do step 1, do step 2, do step 3. And then if that doesn’t work, page a person, And that person will come in and maybe they have a more in-depth runbook and they do those steps and it doesn’t work. And then at some point it’s just like, okay, you have to engage your brain and think about it, right? So a lot of these problems aren’t in the simple space where we could come up with a list of steps that would fix the problem or deal with the situation. So, so it’s, it’s even an issue of we don’t do best practice because We don’t take the time and effort to actually define every node of the decision tree. And even if we did that, even if we could pause our systems and do that, it would be obsolete as soon as we unpause them and they operated for a while and we made changes to them. So that’s why you’ll see me on Twitter yelling about best practice and root cause analysis. Those are my big pet peeves. And people react to my pet peeving about them differently.

Matty: [00:27:19] Well, you know, that’s what, that’s what makes—

Paul: no, that’s what, that’s— I know, that’s what Twitter is good for.

Matty: Yeah, that’s great. So, uh, what’s, what’s wrong with DevOps today?

Paul: That’s, uh, that’s an interesting question. Um, one of the biggest things I see that is, I think, problematic in, uh, DevOps is, um, this idea that we’ve started codifying it and defining it. And once you do that, you start to stamp out some of the emergent behavior. And it’s not like somebody is saying, I don’t want emergent behavior, or somebody’s specifically trying to say, let’s not be emergent. It’s a function of how humans work, right? Once, once people can refer to a definition, they start thinking to themselves, okay, what I’m doing is part of that definition or it’s not, right? So they start bucketing themselves into whatever the process process is or not. So you start losing some of that emergent behavior. It’s actually kind of interesting. It goes back to what we were talking about, best practices. Do you have to be doing continuous delivery to do DevOps? It’s an interesting question. That’s an interesting discussion to have. If you look at DevOps Enterprise Summit, the first few summits really didn’t talk a lot about DevOps. They kind of jumped over to talking about continuous delivery. I mean, 4 years ago, when it wasn’t even in SF, it was at the Marriott by the airport. I remember attending that one, and it was a great conference. The first year in SF too, it was DevOps Enterprise Summit, but then everybody just immediately started talking about continuous delivery. The thing is that I think with a lot of the materials that we’ve seen, we’ve started really defining what DevOps is. I think that can be problematic because it makes it so that we can bucket it. You already see this starting to occur with— if people have heard of Simon Wardley, he does something called Wardley mapping. And yeah, it’s a way to kind of map the terrain of things. He’s already talking about— one of his big presentations, he’s talking about DevOps is what my— you know, he tells a joke. There’s a punchline in his presentation where he’s talking about Wardley mapping. DevOps is what my mom and dad did, right? So, he’s already talking about how— and his big bet is serverless is going to be the end-all be-all, which would be an interesting conversation to have. But the point is, that’s an example of a group of people around a practice, i.e., serverless, that are already starting to say serverless is emergent, and it’s not DevOps. It’s not part of DevOps. Part of the thing that makes that so is that we’ve defined that DevOps is this, and it maybe isn’t some of this other stuff. I think that’s— I don’t know that I would say it’s necessarily something that’s wrong with DevOps, but I think it’s a huge shift from the first few years. I think it’s an interesting shift. If you remember, Matt, I’m sure we’ve all talked about, is DevOps going to become the next capital A Agile? Are we going to have a week-long conference with 5,000 attendees? Is it going to be like a re:Invent type thing?

Matty: [00:30:54] There’s going to be the rugged DevOps and safe DevOps.

Paul: Right. The thing is, to do that, it all starts with defining it so that you can start saying, well, this is what it is and this is what it isn’t. The question is, I think this goes right to that. That question or even that concern that we might be going down that road. It’s capital D DevOps versus, you know, not. So I think that’s sort of one thing to think about. One of the other things that I don’t know that people are talking about, but for those of us that have been around for a long time, I know you have probably seen this. I think some of the early wins are starting to erode. There is not a better example of this, unfortunately, than Etsy. We used to talk about Etsy as a unicorn and an organization that was really doing DevOps right. And there was actually just recently an article in the New York Times about how, you know, their board, you know, made a leadership change. And the article is really about the effects of that. And one of the really interesting parts of the article, and in fact, I tweeted this the other day, That was a quote from the article that was talking about the New York Times went to Glassdoor and pointed out that a lot of the reviews were really bad. And then the reporter found out that HR at Etsy sent an internal email asking people to just say positive things about Etsy on Glassdoor. So I don’t, you know, I don’t mean to make, you know, Etsy, you know, make them feel bad or point the spotlight on them. I know for a fact there are other organizations where they started on really interesting DevOps journeys, they had a lot of initial wins, and then there was a leadership change for some reason, and they no longer are realizing those wins, and they’re going back to the way that they always worked before. I— so I think that’s something that we— that’s something we’re not talking about. And I get why we’re not talking about it. It’s very, you know, visceral and it’s hard to talk about. And it’s— and we’re talking about friends.

Matty: [00:33:17] Yeah.

Paul: And we’re talking about friends, right? We— I know, I know, you know, people at Etsy. I know people at Etsy. I know people at other organizations that used to work at other organizations that have moved on because of leadership changes. And so I think the thing there that is interesting to sort of parse apart and start to think about is it’s kind of like, it reminds me a lot of, you know, we think in technology that we’re all unique snowflakes and technology is unique snowflakes. So nothing of history anywhere applies to us. And I think there’s an interesting connection to be made about the NUMMI plant, right? Which was an automobile manufacturing plant here in Fremont, California that was a joint venture and I’m going to probably mess up the details, but I believe it was Toyota and GM. There was a lot of research that sort of came out because they used kind of the Toyota manufacturing and management methodology to run the plant, but it was American employees and American cars that were being made. I think really what you’re seeing is the argument or the difference between this idea of continuous improvement. We see this idea of continuity going everywhere. The thing, I took calculus like most engineers, and I have nightmares about it, but I really think that’s a good metaphor for moving from discrete improvement to continuous improvement, that we become a continuous sort of function as opposed to a discrete function. The reason I bring that up is that I think it’s really, if you look at cars and what so much of a lot of the DevOps methodologies come from, they come from Toyota. It really did the difference between GM and Toyota. The Toyota Production System was— they shifted the way that they worked way back when. It wasn’t a continuous improvement. It wasn’t an improvement initiative. It wasn’t a DevOps initiative. It was, we need to change the way that we work, and we need to build in this idea of continuous improvement on our methodologies. That’s where they started to pull away from the competition because they changed fundamentally the way they work, and they didn’t see it as a shift in the way they work, and then they’re done. I think that is probably the major difference in a lot of the organizations that you’re going to see whether or not they’re successful in the next 5 to 10 years of DevOps adoption. Is it a short-term thing? Is it something where they hire someone like me to come in and help them with the transformation? And it’s not really a transformation. It’s like, oh, we’ve transformed now and we’re done. Or is it a really fundamentally different way about how you think about the problem of doing the work that you need to do in IT? And then you would come up with other emergent behaviors that are part of that. And that’s where that kind of worries me, because if we just codify all of the practices of DevOps and then we start certifying them, and handing out certificates and certifications, you know, I’m a black belt DevOps or whatever you have, then we’ve removed all of that continuous improvement out of it because we’re not curious about DevOps anymore. We’re not curious about what does that mean because the answers are in a book somewhere. At least that’s the way we think about it, right? And that’s where I think then you can kind of see it in car manufacturing, right? GM, and their performance versus Toyota and their performance, at least historically, right? That failed. Those behavior changes failed to take hold at GM, and that was the difference. So, that’s one of the things that I— those 2 things are something that I sort of worry about from a DevOps perspective or worry about DevOps. There’s a really interesting question, Matt, that I’ve posed before, would DevOps survive a recession? And what I mean by that is imagine a 2008-level financial event. Would this transformation that’s happening in IT, would it survive that? And I’ve had that conversation with a few people, and it’s an interesting kind of conversation to think about because some people argue, well, yes, DevOps provides so many benefits that it would— it’s cheaper and it’s better and it’s faster, so of course it would survive I know you’ve done a lot of transformation stuff with organizations, and it’s like, at the beginning, DevOps is usually more expensive. You usually have to go slower. You usually have to be more deliberate about what you’re doing to make it work. I mean, all of this investment in configuration management automation, that’s a lot of work that you didn’t used to have to do. Companies also tend to be much more risk-averse when the financial world is crashing down around them, right? So, I am not so sure that if we have another recession or hard event in the business world that affects the macroeconomy, that DevOps won’t be the first thing on the chopping block because it’s easier to go back to the way we did things because it’s safer and it’s less risky.

Matty: [00:38:48] Well, and the value proposition of DevOps goes away when you’re in a situation like that, because a big part of why this exists is so that you can be more nimble and you can deliver faster to your customers and do that. When you’re going into this, pulling yourself into your shell to play defense, you’re less concerned about going and you’re not worried about Uber disrupting you, right? Because you’re just trying to keep the lights on. You’re not innovating at that point. Again, you’re playing defense. That’s the whole point, right? If what you’re doing is playing defense, then DevOps doesn’t help you.

Paul: Right. Well, and that’s the thing. What you just said is entirely correct, but in a financial event like the 2008 crisis, I don’t even know that the thinking is happening that way. It’s OMG, we are hemorrhaging money. What is this line item for DevOps transformation? Get rid of that, right?

Matty: [00:39:53] Sure.

Paul: So it’s not even, oh, can we outcompete Uber? What does that look like? It’s like, oh, we don’t have, you know, millions to spend on this anymore, or whatever it is, right?

Matty: Well, I’m saying it’s 2 things. One is like cut what you already have, but you’re also gonna see companies that haven’t transformed—

Paul: oh yes—

Matty: aren’t going going to.

Paul: Yep.

Matty: Because they don’t have the driver to do it. Right.

Paul: Yeah, totally.

Matty: That’s— yeah, it’s twofold, I think.

Paul: Yeah. So I’d actually, to be honest, I would, you know, if listeners listening to this, I’d actually be curious what your take on it is because— and feel free to, you know, start the conversation on Twitter about it because I’ve had people argue it the other way. I’ve actually had people argue that if you have sort of leaders that are in a position of power in the organization where they can do it and they’re transferring their kind of go-to on how they lead to transformation, they might actually double down on it, which is an interesting argument to make. That’s why I think it’s a really meaty conversation to have. I’m curious what I think— we will have a recession again at some point, and hopefully it’s not as bad as 2008, but it will be curious to see what happens there and where we fall back to. There’s one last thing I would say that worries me. I wouldn’t say it’s wrong with DevOps, but worries me. I was actually chatting with Sasha Bates, who was one of our podcast co-hosts on The Ship Show. And she’s kind of, you know, we were talking about it and we were just chatting about what she was doing and working on. And she was kind of mentioning, yeah, I’m kind of over DevOps. You know, the kind of impression that I got from our conversation was she was kind of like, you know, the moment has come and gone. That kind of magical moment that sort of brought us all together. That’s one of the things that I talk about a lot. I was really lucky starting consulting when I did, and I met a ton of amazing people and had that opportunity. That, I think, was just random within the industry, just random industry shifts. But a lot of people that I know, Matt, you and I know, that were luminaries and really influential in beginning DevOps, have sort of tapped out of it, right? They’re just like, yeah, it’s not what it was. And not only is it not what it was, it’s to the point where I don’t want to be a part of it anymore. And from a continuity perspective of what we always talk so much about, tools and culture, tools and culture, from a cultural perspective of what it means to be a DevOps community, even a macro community, but even, you know, even a smaller micro community, I think when you lose a lot of that talent and that context and that history, I worry what will replace it because something will replace it. And so that’s what I worry about DevOps.

Matty: [00:42:58] Yeah, I feel like there’s definitely— well, what is it? It’s the Gartner thing. It’s the trough of disillusion, right?

Paul: I mean, that’s 100% true.

Matty: And it’s funny because I’ve been thinking about this specifically because I’m starting a new job on Monday where my title is DevOps Evangelist.

Paul: Congratulations, by the way. Thank you.

Matty: By the time y’all are listening to this, I’ll already be there.

Paul: You’ll firmly be in the job, but yes.

Matty: And I was sort of thinking about that. I was like, well, so that’s great. Now that’s not a thing, but not that it’s not a thing, but I think that’s where we are. And I also have seen Um, I think that’s just the thing that happens with— I don’t want to say early adopters because the, the kind of folks we’re talking about aren’t really necessarily adopters, but things do change, right? You know, and, and we can sit and we can kind of, you know, tear our clothing and gnash our teeth and say, well, it’s not what it is, you know, and it’s—

Paul: this is not what it used to be. Yeah, this is right. This is where Grandpa Paul comes in, right?

Matty: [00:43:59] Yeah. And, and it’s, it’s kind of this thing, and I— oh man, I can’t remember the But we, you know, we were talking about this, um, at— I was talking about this, um, you know, as you kind of go through it and it’s like you— there’s this— you start with early adopters, right? And early adopters are people that will take the thing warts and all. They’ll deal with the rough edges because they believe in it. They want to do the thing. And then it’s like the, the optimistic something, right? They’re the companies that are there. They tend to be people— companies who are like, okay, I, I buy this. This is good, but they have different types of requirements, right? Your early adopters are the ones who are like, just sort of give me an API and give me a big toolset and I’ll figure it out, right? But then when you get to that next level, it’s like, you know what, we do want— and, you know, lack of a better term— best practices. Or they want recommendations, they want direction.

Paul: Sure. But so here’s—

Matty: but I’m just saying, that’s sort of where we’re transitioning. And I’m not saying it says that it needs to be codified, but what’s happening is this thing that was sort It’s almost like you think about the Mac team, the team that developed the Mac, and they were rebels and they had their pirate flag and all this. That’s how the people, if you think about it, if you were in DevOps from the beginning, that’s who you thought you were. You were the rebel, right? Here’s the thing. It’s like, do you ever watch the show? It’s this show on the BBC called Coupling. It’s really funny.

[00:45:21] Okay. Well, anyway, the whole gist of it was there’s this point, and I don’t remember political parties in England, in the UK, well enough to know what it was. But it was that the, the one woman was, you know, she was used to being whichever party she was that was the, the downtrodden one. And, you know, her boyfriend was like, no, you’re in power now. And she’s like, no, we’re the good ones, we’re the rebellious ones, right? And it’s like, that’s the thing. It’s like, well, when, when you, when you win the revolution, you are not— what that thing was is now the normal, Right? And so, if what you were enjoying was being that gadfly and being like the disruptor, well, the shit got disrupted.

Paul: Yeah.

Matty: No, no. Now we’re just doing some work.

Paul: Right. And that was the funny thing. I think Dave Mangot from Salesforce said that at the Ghent recording on The Ship Show. He was saying that in 10 years, we’ll just call DevOps going to work. And that’s good. I mean, if you want to shift the lens and ask what’s right with DevOps, Ops. I do think that, you know, let’s assume that, you know, and these are all made-up numbers, right? But let’s assume that like the unicorns, the Netflixes and the Etsys and whatever, that that’s 100% DevOps. I guarantee, and I know you’ve seen this, that if an organization takes 20% of DevOps and whatever that is, right, they configuration manage stuff or whatever it is, right? And that sticks. Their life is still gonna be better, and that’s good. And but to the point though, and I think you, you said it really beautifully, when we sort of codify it and all of that, you have a bunch of organizations, large organizations now, that are like, yeah, this doesn’t, this doesn’t work for us. How can we make it work for us? And if we lose that emergent behavior, then there’s no space for us to invite them in a credible way and say, you know what, your problems are really interesting. Let’s come together as a community, as a culture, and help you figure that out. Because we’ve got a set of people saying, no, DevOps is what’s in this book and everything else is not DevOps. We used to not have that, which was bad, but there’s also a positive aspect to that. And so that’s the thing that I think we’re going to see in the next 5 years as a community. We’re going to wrestle with that, and it’s going to be interesting to see how it pans out. But I do think we’re in, you know, that maybe not the hype cycle, but the adoption curve. I think we’re past that chasm. And so, you know, I think, you know, Gene Kim always talks about, you know, improving the lives of millions of IT workers, which is, you know, a tall order. I think DevOps does have the power to improve that many IT workers’ lives. The question is, are they ever going to get to, you know, the DevOps nirvanas that we hear about, the DevOps unicorns? And is that, you know, how do we feel about that? And that’s an interesting question. How do we feel as a community about that? Maybe 20% or 30% improvement in those people’s lives is enough.

Matty: [00:48:38] The needle is moving, right? Yeah, definitely. Definitely. And that’s one of the things that I agree, I would absolutely agree with Gene. And it’s one of the things that I’ve really loved with working at Chef is because I’ve been in the shit, right? I know how much it can suck and I know how doing these things makes things better. And I know that that’s a thing. It really is. It’s like this is making people’s lives better. That’s pretty awesome to be a part of that. But like—

Paul: I’ll give you one really good example. I worked with a client. And they had a lot of challenges. One of the things is their IT staff just— they had a maintenance window every Saturday night, and their IT staff worked every weekend from like 10 PM on a Saturday to like 3 AM on a Sunday. That was their window, and they just did that every week. I remember talking to them about that, and they just didn’t see a problem with that. That was like, that’s what we do, and That’s how our system works, and they saw no issue with that. Even if that organization never ever gets rid of that, if from an industry perspective, they can see some of the presentations at DevOps Enterprise Summit, they can see some of the work that Nicole, in her new book, talks about how you can move quickly and move safely at the same time, and some of the practices that it takes to do that, even if their organization doesn’t change, but they go, you know what, my life could be better if I get another job somewhere else. That’s still a win, even if it’s not the win that we might think it— we would like it to be, you know? Yeah, for that organization.

Matty: [00:50:21] Just, just like you said, an organization is never going to be done. The industry is never going to be done, right? We’re not going to be like, and you know what, and because we’re going to be moving to the next way to make things better because the world is going to change.

Paul: Yep.

Matty: And that’s— that DevOps was reacting to the things where, hey, we tried doing things one way and it really wasn’t working out, especially as our world, the actual literal world, changed. And the world is going to continue to change. And you know what, 10, 15 years from now, we’re going to look back at how we did DevOps. The way we do DevOps today will not make any sense in 2030, right?

Paul: Sure. But so the question is, do we still call it DevOps then? Right?

Matty: We probably won’t.

Paul: Naming things is hard, right?

Matty: Yeah. And it’s funny, I just actually recorded an episode right before I was recording with you, um, with, uh, Aaron Rinehart, and we were talking about, uh, this, uh, security tool that his company, uh, intersourced to open source. So we’re talking a lot about security and we’re talking about the DevSecOps thing, and I was just like, it’s— yeah, it’s funny that, you know, DevOps is actually an unfortunate name because it implies it’s just dev and ops, and I think we all No, it’s not.

Paul: [00:51:25] Right.

Matty: Um, and I also had to chuckle when you, when you made that comment about, you know, DevOps being going to work. Uh, a fellow I’ve worked with for a long time, when he came to, to work for me at 10th Magnitude, um, and was— that’s when he started learning about DevOps because he was coming to do that. And after he kind of did some stuff, he’s like, I’ve been doing this for a long time, but I just called it work. Right, right. And it’s— that was the, the thing is like, uh, I can’t remember if it was Patrick Debois or Damon Edwards who tweeted, uh, it was a couple years ago, he said we should just rename DevOps common sense. And I said, yeah, but that won’t fit on my license plate.

Paul: Right, right. Well, here’s the other thing, like, like, seriously, you know, we spent a good, what, half hour, 20 minutes, half hour talking about like the issues and the concerns and things that worry me about DevOps. But, you know, giving— the reason you kind of don’t actually want to call it common sense or going to work is because there are a set of practices and patterns, right? Good practices, to go back to that Cynefin thing, that really influence in a positive way not only organizations organizations and people. And you literally cannot talk about them unless you have the words to talk about them. And DevOps gives us the words and the context to have those conversations. So in that regard, yes, we might, the industry might shift where most of us, you know, 80% of us are doing some form of DevOps, right? But we do risk that the challenge of if we can’t describe it anymore, then, then we have a problem talking about it. You know what I mean?

Matty: [00:52:50] Absolutely. Yeah. I mean, I think that’s, again, we’re just sort sort of joking about it being like that. But you’re right, you still have to think about that. It’s a different way of thinking and an evolving, an always evolving way of thinking. So who should we be listening to that we aren’t listening to?

Paul: Well, I think, and I’ll full disclosure, this is a little bit of an area that I’m super interested in. So it’s sort of, I’m a little biased. But I think a lot of the work and interest around what the safety sciences have to bring to the operation of IT systems is really important. I think starting to really look at, you know, automation is still a big thing, looking at other industries doing that. So this is the work that I’ve been doing, the work that John Allspaw has been doing. I know there are people going into that area from the chaos engineering community, they’re getting— they are getting really interested in this, right? So There’s an interesting swirl if you talk about DevOps and then the security community, DevSecOps. Then you also talk about the safety-critical systems or systems that we build that we don’t even know they’re safety-critical. I’m willing to bet that AWS is in some way safety-critical in a way that we aren’t aware of. There’s some system relying on some service that relies on something that’s in AWS, and we can’t map that anymore, right? So I think we’re going to be, you know, I think as an industry, because of the pervasiveness of technology, we certainly know that certain technology is safety critical. But I think we’re— there’s a huge shift in our industry to really take that responsibility that all of the technology, at least in some way, is probably borderline safety critical. And, and the reason we would do that, here’s the important part. I think it’s going to influence the way that we work, which is important. But the other thing is, we need to take ownership of that. Because, and this is something that John Allspaw just said at DevOps Enterprise Summit, and in his talk, you know, if we don’t own that criticality, maybe not safety critical, but criticality of the software and services that are, that play a role in our society, if we don’t own that, somebody else will. And I mean regulators and lawmakers will own it for us. And that’s where you get people going to jail for things. And if we’re not okay with that, if that concerns you, we need to start having those conversations big time because we got to catch up on that conversation with other industries and we need to start owning that now. So I think that’s a big area that we should start listening to more. And then of course, I would just mention I put a plug in for release engineering because I think release engineering isn’t going away. I think with Internet of Things, it’s getting worse. And I had an epiphany the other day that, and this was Michael Stahnke from Puppet. He, in his talk, was talking about how ops people, he gave a keynote at PuppetConf, and he was talking about how ops people have become the, you know, the shift for them in sort of this DevOps thing is they were asked start pushing the bits out the door, like, go take this package that is our website and our service and put it on all these servers. So, they became— your operations team became de facto release engineers. But the thing is, a lot of operations people don’t have any training in release engineering. I mean, that’s not a comment on them. They’re busy running distributed systems at scale and keeping the lights on and all of that. So it’s not a comment on them. But, but I had this realization, and this happened a lot on the Ship Show, where, you know, Sasha has— Sasha and I would talk about things. And I found out I thought release engineering and operations were a little closer than they actually are, because we would use words that neither of us had heard. And so we would talk about that on the show, about what we meant by those words. And so there was an exchange of knowledge that was really good. So I think release engineering engineering is still a big thing. I think it’s going to get bigger with, with DevSecOps and software supply chain. Um, and I think so, I think we need to also pay attention to that.

Matty: [00:57:19] Absolutely. So, uh, speaking of Michael Stahnke, uh, he has 2 questions for you. Uh, so his first question—

Paul: and I probably, I always butcher his name anyway.

Matty: Yeah. His first question for you is, when is the Ship Show coming back?

Paul: Uh, that’s a very good question. Um, so, uh, there are current plans, although there have been conversations actually about what— how we could do it in a more sustainable way. And there have been conversations with some of the co-hosts. I’m really proud of The Ship Show, and I’m actually— I think one of the things I’m most proud of it is the last episode, because burnout is still a big problem. It was front of mind for a lot of people back then, and I think it made a point that like, you know, we’re burnt out on doing this. And that’s how we did what was right for us. But there were conversations about it. I still actually get sometimes people pinging about, can we buy ads on The Ship Show? And I have to be like, well, you can give me your money, but I don’t know. Well, I don’t know. It’ll be— it may be a while since it sees the airwaves, as it were.

Matty: [00:58:30] Well, I will say, if you ever want to do like a reunion show.

Paul: That would be fine.

Matty: You’re welcome to.

Paul: That would be fine.

Matty: I’ll give you the reins. It’s funny. Okay. Charity, Charity asked, like, we, we had this theory and we’ve just never done it because she had people she wanted to interview. I was like, well, I’ll give you the, the reins of the show for a couple episodes if you want to do it. And, you know, we’d start talking about that beginning of the year. It never happened. But yeah, you know, you can, can always borrow our, our audience.

Paul: And, uh, yeah, no, that’d be fun to do a reunion. Yeah, reunion episode.

Matty: Uh, Stucky also wants to know, what’s the most heinous build system you’ve ever seen, and did you build it?

Paul: Um, well, so I think there’s, there’s, uh, a distinction to be made between heinous and complicated. So one of, one of the— I think in terms of, of heinous, or just things that a build system that was just very not good, I think any build system that is doesn’t really serve developers well, actually doesn’t serve all of the users that need it. So sometimes that’s QA people, it’s definitely release engineers, and it’s definitely developers. That sort of can be a heinous build system. And I see us moving backward as an industry in terms of build systems. So the example that I give is how many build processes— like, like the analogy or the heuristic I always give is, can you build on a train? And most people, it’s like, no, I can’t, because the build system checks out submodules in the middle of the build, or the build system does an npm install in the middle of the build. So I literally can’t build on a train because I have to be connected, right? And so, you know, there are, you know, the biggest thing that I see now is, as we try to integrate a lot of the different types of technologies, build systems that like always rebuild things, right? And I think again, that goes back to to. Release engineering is important. Those are problems release engineers used to solve. And now we’re getting this mishmash of developers are designing build systems with their use case in mind, and that’s fine, right? And then, but then operating ops people, operations people also have to use it. So they bolt stuff on, and you get this thing that’s kind of this Franken-build system that is not really great for anyone. And that’s where, you know, the art of release engineering really comes in. Now, I want to say one last thing about about that. I made the distinction between heinous and complicated. There was a build system that I worked on that was very complicated. It wasn’t so heinous, it was just complicated. And it did things like the product built on Windows and Linux and Mac, but components of it had to be built with GCC. Very low-level assembly-level components had to be built with GCC. So the build system had this weird flagging mechanism where it would, like the Windows build would start building and then it would pause and wait and then tell via NFS a Linux machine to start building the components it needed. And so it would build it with GCC and then drop the components back on NFS and the Windows build would continue. And when it was this really bad, like handshaking, whatever, that was, that was pretty complicated. Parts of it were pretty heinous, but yeah, I haven’t written any of those. People hire me to fix that stuff.

Matty: [01:01:51] Josh Zimmerman, who is the Juberwocky on Twitter.

Paul: Hey, Josh.

Matty: Yeah, he’s hilarious. He has some of the best tweets. One of my favorite Ignites that he gives.

Paul: Yeah, I was going to say, he does the DevOps Jax candy. Yeah, yeah.

Matty: Josh wants to know, what is your favorite source control management system and why is it Git?

Paul: So a lot of people, especially from if you listen to the Ship Show, think that I hate Git. And the thing is, I don’t hate what Git allows us to do. I hate that Git— I hate Git’s user experience. I hate that Git was bolted together in a weekend. And I don’t— there’s a great— I’ll see if I can pull this thread up. There was a great proposal on the Git mailing list recently. About they wanted to add release management capabilities to Git. I wrote this whole big long thread of why that’s a horrible idea. The thing is, I use Git, I use it daily, I help teams use Git better, and you usually have to do that because there’s so many workflows, and if you all use different workflows, it’s a shit show. In fact, there’s a blog post from 2014 on SysAdvent, which I was looking at because I’m helping out this year with that. And some of the—

Matty: [01:03:07] some of those, by the way, speaking of, I need to finish writing my— Chris Weber, like, let me know. He’s yelling at you the day before Thanksgiving. Oh, by the way, your post is supposed to be published on December 2nd.

Paul: Yeah, you better get on that.

Matty: I know.

Paul: That’s what I’m doing. But anyway, those were Git tips from 2014. One of them is on your team, have a Git language lawyer, right? If you have like code C++, you have a C++ language lawyer, have a Git language lawyer that knows all of those details and can help you with that. That’s super important. So I don’t, I don’t hate Git. I just hate its user experience. Absolutely. I think we can do better.

Matty: Yes. Final question.

Paul: I love everyone, Matt.

Matty: Yes, everybody, everybody. Final questions from Jason Dixon, who says, when did you finally realize that Five Guys is better than In-N-Out.

Paul: I don’t think I’ve had that realization yet. Sorry, Jason.

Matty: The fries are better.

Paul: Well, now wait a minute. Aren’t Five Guys the really, really thin fries?

Matty: [01:04:09] No, no, they’re not like super thin. But they’re not like steak fries. They’re pretty good. Maybe it’s just because they give you so many and I’m a glutton.

Paul: Now, is Five Guys also the one that does the peanuts?

Matty: Yeah.

Paul: While you wait? Yeah, I don’t know. Yeah, yeah, yeah.

Matty: I—

Paul: so it’s funny, the last time I went to In-N-Out actually was during Velocity, and Pete Cheslock came in. He flew in and—

Matty: to go to In-N-Out?

Paul: No, well, he flew in for Velocity, but he’d been drinking the entire flight, which is his signature Cheslock move.

Matty: And he was like, it’ll get you where you gotta go.

Paul: It’ll get you where you gotta go. Yes, that’s also a Cheslockism. But so he was He was like, I need In-N-Out. Can we do In-N-Out? I was like, okay, because I had a car. And so we went to In-N-Out. So I still, I don’t know, I got to represent the California In-N-Out.

Matty: I can dig it.

Paul: Yeah.

Matty: Awesome. Well, this has been a lot of fun. Yeah. Let me just get some updates here. So just a couple community and event stuff coming up. Basically, there’s a bunch of open CFPs, a bunch of DevOps Days opened up their proposals. So if you go to devopsdays.org, conferences.org/speaking, you’ll see all those. And by the way, you can thank the aforementioned Bridget for writing the code that makes that show up cool like that. Velocity has theirs open. So if you go to conferences.oreilly.com/velocity, and ChefConf, which will be in Chicago this year, which I think is kind of cool because, you know, I’ll be able to go to it for sure. So the CFP is open for that, and I meant to write it down, but you know You know what, Google ChefConf CFP and you’ll find it because that’s what I was going to do to give you the link. We’ll probably put it in the show notes if I remember. Speaking of show notes, if you go to arresteddevops.com/grandpapaul, that’s where they’ll be. On the site, you can sign up for our newsletter, The Banana Stand. Also, by the way, I keep forgetting to tell people, but people always want stickers. You can either, if you find me somewhere, if I’m at an event, I probably have some, but if you can’t wait. If you go to arresteddevops.com/stickers, you can buy our stickers from Sticker Mule. We sell them for cost. We’re not making any money on them or anything. So go ahead, throw them all over your laptop and stuff. It’s pretty cool.

Paul: [01:06:27] Matt is not going to Hawaii on your sticker revenue.

Matty: Not on the stickers. No, sorry. And yeah, if you go to arresteddevops.com/itunes, leave us a review in the iTunes store. You know, it helps other people find the podcast. And yeah, Paul, thank you for joining me today. I’m glad we finally got this.

Paul: Yeah, yeah, it’s not going to be years before we do it again. Yeah, it’s been a long time coming. Thanks for inviting me, and I want to wish everyone a happy holidays. I’ll see you on the Ship Show reunion episode.

Matty: There we go. Absolutely. So yeah, I’m Matt, @MattStratton on Twitter. This is Arrested DevOps, and remember, there’s always DevOps in the banana stand.