Matty: [00:00:05] Hey, welcome to the very first real episode of Arrested DevOps, the podcast that probably won’t destroy your career with bad advice. I’m your host, Matt Stratton, @MattStratton on Twitter.
Trevor: [00:00:19] And I’m your co-host, Trevor Hess, @TrevorGHess on Twitter.
Matty: [00:00:24] So this being the first episode, we’re going to talk a little bit about how we’re going to structure things here. Normally, at this part after our intros, we would do something we call the sprint retro, where your hosts would tell you — we’d talk about what we might have learned since the last episode. Since there is no last episode, although we did have an episode 0 — and we’re not going to tell you our entire history because nobody wants to know that. Instead, we’re going to talk a little bit more about what the point of this podcast is, if there is a point to it, and what we want to do here. So the question is, why? You know, what’s our point? So, Arrested DevOps is a podcast that’s focused on sharing ideas and concepts related to DevOps and things like that: continuous integration, continuous delivery, software engineering, release engineering, configuration management, all that fun stuff. But our target audience is not your super deep, knowledgeable DevOps guru, but rather software and infrastructure practitioners, people who want to know more about DevOps and how it can help them. So, so why, why does the world need yet another DevOps podcast? There’s some great ones out there, and I’ll link to them in the show notes. For me, and then I’ll let Trevor talk, but for me, I want to help DevOps newbies get ramped up on the ideas so that it makes it easier to consume the advanced material that’s already out there. Also, I have opinions, and the internet needs to hear them. And also, I’d like to get some people outside of the technical part of the software delivery process involved. We’re hoping to be able to talk to people like product owners, maybe DBAs, you know, people outside of your usual sysadmin, DevOps-y, developer-type person that you might normally think of when you think of DevOps.
Trevor: [00:02:11] And I’m really interested because, for me, this is kind of the realization that, as a developer, I’ve been doing all kinds of DevOps. And kind of putting a face to that in my own context. And that’s what has me excited about this, is being able to kind of talk through the issues that before I didn’t really have a name for. It was just, you know, stuff that goes with my development processes. And so that’s kind of what I’m here for.
Matty: [00:02:42] So that being said, a couple things we want to say. What is Arrested DevOps not? One thing is, we’re going to try — I’m not saying we’re going to accomplish this, but we’re going to try to not be judgy when it comes to technology. We do believe in the right tool for the right job, but the right tool may differ from situation to situation, which is kind of a nice way of saying you don’t have to feel dirty for using Microsoft when you listen to this podcast.
Trevor: [00:03:14] But you don’t have to be evangelical about it either.
Matty: [00:03:16] That’s right. And speaking of tools, we also don’t want to really be super tool-focused because I’m fond of saying that tools are easy. People are what’s tough. And so this is not where you’re gonna — we may have tools episodes, I don’t know, this is our first one, we don’t know what we’re doing. But our focus is not on tools. There’s better podcasts that will really get into that, and you should listen to them. And the other thing is we’re going to try to avoid that kind of inside baseball thing as much as possible. We will, I’m sure, be often quoting and referring to experts and people who know better than we do, but we’re going to really try to steer clear of name dropping. So you’re not going to hear me say, you know, when I was talking to John Allspaw at Velocity, but you’re also not going to hear that because I have never talked — I’ve never spoken with John Allspaw at Velocity. So it’s safe to say. So now we know what we are and what we’re not, which brings us to the logical question, which is, what is DevOps? And that’s what we want to talk about. So Trevor? What is DevOps?
Trevor: [00:04:34] Well, for me, that’s a little bit of a loaded question because, as I said, I’m kind of realizing what that is to me. So, to me, DevOps is kind of the bridge between the tools that I need as a developer to build my software more efficiently and the bridge between doing it and just doing everything manually every time. And kind of making a lot more things automated and consistent. So, like, setting up continuous integration servers, setting up build servers, setting up all that kind of stuff that helps facilitate the bridge between straight development and a product.
Matty: [00:05:19] So do you think — is DevOps, is that a role? Is that a title? Is that something — can someone be a DevOps? I think absolutely.
Trevor: [00:05:29] I think there are people who facilitate that. In my experience, it’s kind of something a developer does to support his own work or to support a team’s work. It’s not necessarily something somebody’s committed to at all times, but there’s definitely somebody out there to support that role.
Matty: [00:05:49] And see, and that’s where it gets kind of, for me — one of the things that kind of riles me a little bit is when people will say, hey, I’m hiring a DevOps engineer, I want someone to come and do my DevOps. I know we just got done saying that we’re not going to name-drop and do inside baseball, but John Vincent actually wrote a pretty awesome blog post about this, which we’ll link to in the show notes. But it fundamentally is what he says, and I’m not going to quote it completely because a lot of it is not appropriate for our audience as far as language goes, but basically he says, DevOps means giving a blank about your job enough not to pass the buck. DevOps means giving a blank about your job enough to want to learn all the parts and not just your little world. And right now, this is the part that I think resonates with me and is my whole philosophy about it that John says. He says, developers need to understand infrastructure and Ops people need to understand code. People need to work with each other and not just occupy space next to each other. And to me, DevOps is — it’s not that slide of the developer and the ops person hugging each other. It’s not like, hey, everybody be buddies, because the truth is, even in culture, in company cultures that I’ve been in where there’s been this so-called wall, right, the people still like each other. They don’t punch each other and then walk past each other in the hallway. They might say nasty things about each other behind their back, but they’re not having fistfights or anything. So this isn’t about let’s team build and let’s be in open space and whatever. It’s about, for me — so you said, it’s developers need to understand that what you write, it’s got to run in production. It’s a real thing and someone’s supporting it and it might be you. And it might not be you, but it’s running the business. It’s important. And then ops people also need to understand how the app works. You can’t have this like, okay, I don’t know, that’s an app thing, right? I don’t know, the server is running, Apache is running, IIS is running, I don’t know what it is, I don’t know what your logs mean. And to me, the classic example of this, of what DevOps is not, is when it comes to something like error logging. [00:08:00] And I’ve many times been in that room with the developer and the developers and the tech ops people on the project, and it’s now come to the last sprint, and now it’s time to talk about logging because these stories got pushed off to that very end. And that’s something else we’ll talk about. And then all of a sudden, it’s like, okay, well, we have the story to do logging. And the developers turn to tech ops and says, what do you want me to log? And the tech ops says, I don’t know, what does your app do? And this is a problem for both things because both parties are basically saying, not it, I’m not the one that needs to do that. And it should go the other way. And to me, that’s —
Trevor: [00:09:02] How do we do this together?
Matty: [00:09:04] You’ve done that, you know, had to kind of deal, like you said, in what you’ve been doing, you’ve had to say this stuff actually has to run. You’ve been in a DevOps culture, maybe by necessity more than by choice.
Trevor: [00:09:16] Yeah, that’s probably a good description of it.
Matty: [00:09:19] What do you think would be some of the things that if you’re trying to get it across, maybe some concrete examples of in your day-to-day, and I know you’ve given some, but maybe a little more about saying, okay, this is what I do that I think would be different if I was in a culture that was more walled-off command and control, whatever?
Trevor: [00:09:40] Well, I mean, I’ll start, you know, kind of with what I’m most familiar with most recently, and that’s kind of setting up a CI which continues running all of our tests as well as managing deployment to our testing servers and, you know, it’s not quite production server yet because we’re not that far along yet, but our user acceptance testing servers at this point. It’s the kind of thing where, as a developer, I’m also responsible for — not only am I responsible for writing the code that’s going on the servers, but I’m also responsible for knowing what the instances are, knowing how big they are, knowing when we need to scale them, helping to facilitate scaling them, that sort of thing. We kind of set up some template servers. That’s the kind of thing where, if we did have more defined roles between development and operations, those are things I wouldn’t handle. Those are things that, as a developer, I would go and say, hey, the application’s no longer running smoothly, what are our options in terms of expanding? Basically the questions that I get asked now about the servers we’re running on. [00:11:00] Just recently, I had to scale up our database server because there wasn’t enough memory to run our ETL process. It was taking 6 hours, and we had to figure out how to make it faster because that was taking way too long. In a more defined environment, I think that issue probably would have been discovered sooner and not had to have gone through or waited for me.
Matty: [00:11:29] One thing I was just thinking about the other day when I was thinking about this topic and knowing what we’re going to talk about, it made me wish that Facebook had a better way to search your old stuff. And I’m sure there is a better way, and maybe someone will tweet me or comment here and tell me that I’m dumb and I don’t know how to do it, but I really remember being very quote-unquote anti-DevOps a few years ago. It just rankled me. And it was because I didn’t understand it. And this is — here’s what your average, and not to put words in people’s mouths, but you know what, this is what your average TechOps or sysadmin thinks when you say DevOps. They think, oh, the developers want to have admin access to production, crap, no, no, no, no, no, no. Who’s going to do that? Who’s going to manage that? And I remember in this Facebook thread, and I don’t remember why, I think it was something I read on like Agile Sysadmin or something that made me start this discussion. And that was the thing, I guess, of all things to get really wound up about, I got really wound up about patching. Because I was like, okay, that’s fine. So if the developer, you know, when we’re in this DevOps world where the developers get to push their own code and they get to have root in production and blah, blah, blah, I’m like, who’s going to patch those servers? Who’s going to do the things that aren’t sexy, that the rough and tough sysadmins do and blah, blah, blah? [00:13:00] Again, I really wish I could find this because it was just such a complete miss that it’s not — first of all, you still have ops people. You still have people whose job is to care and feed for this stuff. I mean, sometimes they are the same person. I talked to someone at a startup one time, and we were just chatting and got in the conversation about DevOps, and he’s like, yeah, we’re DevOps because you know what, I’m the dev and I’m the ops, we have 3 people in our company. But even in a small company, you can still end up wearing multiple hats, and you could even put that wall for yourself. And I think people used to do that. But it’s really hard where you can kind of have this difference on this perception of what DevOps means. Ops, they get scared because ops, we like command and control, because it’s our ass that’s on the line when that stuff is down. That’s what’s gonna happen. Web server goes down.
Trevor: [00:14:10] Even bouncing between the two, you know, when someone says, can I just make myself the administrator on the VM? And I might, you know, in reality they’re probably not gonna do anything bad, but that little control part of me twitches and says no. You can just type the administrator password that you have access to.
Matty: [00:14:28] Yeah, and it’s like a great quote I heard once which said, every time someone logs onto a server interactively, they compromise everybody’s knowledge of that system. Because again, like you said, they’re probably not going to do anything, but I don’t know what you did. But back to my point — the ops person is thinking that I have to protect my fiefdom because I’m the only one that cares, right? Developers are the ones that are writing this code that’s going out there and breaking stuff. And for God’s sake, what would happen if there wasn’t this thin blue line of TechOps to keep things in check. And in the meantime, on the other side, you’ve got the development side sitting there saying, oh my God, TechOps are just such a stopper. Well, why? Okay, sprint review, why didn’t you get story points? Oh, I was waiting for TechOps. And it’s, after blaming environment differences, it’s the easiest thing in the world to blame because everyone’s used to it. And the fact of the matter is on either of those, neither of them is okay because neither of them is true. TechOps, or Ops if you will, having this belief that developers just want this Wild West thing and they’ll go willy-nilly and not give a care in the world, it’s ridiculous. Because they don’t want to be the one that makes it go down. We all work for this company. What’s the vested interest in making it fail? Then likewise, for someone on the dev side to turn around and say, oh, TechOps is my stopper, because it’s easy, because I want to point a finger, chances are TechOps isn’t in the room, which is why you can say that. That’s irresponsible and incorrect as well. I think that’s — at the end of the day, that’s DevOps, right? It’s flattening. It’s like, oh, I’m gonna give a little shout out here. We just got tweeted by the Food Fight Show. They are watching us. [00:16:00] So, okay, now I’m all nervous like my podcasting heroes, and I’m not going to name-drop them, but hey, Brian and Nathan. So let’s switch gears a little bit. We’ve talked a little bit about what it is, and Trevor, get your thoughts too, on what is it — let’s kind of define what is it not, right? I alluded to this before and I said it’s not, in my opinion, it’s not a person. But what are maybe from what you’ve seen or read, what do you think are maybe some of the fictions? Or if this was a BuzzFeed article, it would be like the top 20 things that people get wrong about DevOps, but we’re not going to do that.
Trevor: [00:17:22] But people love lists.
Matty: [00:17:24] Yeah. If we were better prepared, we’d have it.
Trevor: [00:17:30] Right. Well, this is our first episode, we got things to learn, we’ll make better bullet points next time. So I think it’s not inherent — you kind of nailed the biggest of them is, it’s not about finding a scapegoat. That’s one of the big things that I think, as you said, in any kind of situation where you’re bridging the gap, one side’s blaming the other for something.
Matty: [00:18:00] The other thing that I’ve thought about as well is that it’s something that’s interesting, and one of the things when you talk about being prepared, but I really wanted to do this and I didn’t quite get everything, but I went and I did a search on CareerBuilder for the keyword of DevOps, because what I found in my experience is that DevOps is the new sysadmin. There are no jobs listed for sysadmins anymore, they all want DevOps engineers. But then you read the job description and it’s a sysadmin. It’s like, hey, we’re looking for a DevOps engineer to join our practice and to manage our farm of Windows 2003 servers and be responsible for patching and resets as appropriate and deploying, doing weekly code pushes with Robocopy. I’m like, that’s not DevOps, that’s what a sysadmin does, you just called it something different now. So, we have a question from the Twitters. Brian says, can you have DevOps in a situation when you have ops plus maintenance programmers and the original devs have moved on? I think that’s a great question, because a lot of this, we’re talking about it in terms of new feature delivery, right, we’re talking about, you know, kind of if we’re on products that are in the scale of innovate as opposed to maintain. And I think in a lot of ways, it almost lends itself more to the DevOps thing because it goes back to the — you don’t have as much, you’re not driving as much innovation, so you’re not moving as quickly. So it lends itself to, if we say that part of DevOps is that people who are involved in all parts of the work are responsible for keeping it maintained, or at least keeping it operational. Absolutely, I think that’s a great way.
Trevor: [00:19:48] Yeah, honestly, I think if they’re not working together, in some capacity, and I’ve seen it a couple places where they’re kind of, again, they’re the same person, the maintenance crew is the ops crew. If you’re not working together, especially in a maintenance situation, you’re gonna run into tons and tons of problems. I push a code change, and you’re in the middle of resetting the server, we’re not working together cleanly, we’re not talking, we’re not coordinating.
Matty: [00:20:34] Yeah, and I can absolutely give an example of an organization I was in where, and this was before the organization had moved to Agile, although that was really irrelevant, but also wasn’t looking at things from a product or certainly not from a DevOps perspective. But we had software engineering whose responsibility was basically new feature stuff for product. So product would come in and they would give projects to — so this is the old waterfall stuff, right? And then you had TechOps as a totally separate group whose job was keep the lights on, but also do basically whatever software engineering needed to be done. So we did the releases, there was no real release engineering, but we would do the pushes and environment refreshes, blah, blah, blah. And then there was this production support group and they were pretty much just developers, and they did all the bug fixes, and then everything that, for lack of a better word, everything that wasn’t sexy. It kind of was a really crappy place to be, and God bless those people, especially God bless their manager, because for most of the engineers, it was just this stepping stone. It was like, hey, I’m gonna go do my time in prod support, and then eventually I’ll go get to be an engineer and work on new projects. [00:22:00] But to my point of — so this is why it didn’t work, was what you would have, because it wasn’t in a DevOps model, where you had the prod support would go there and they’re dealing with issues, because they’re getting customer complaints, internal or external, whatever, and they’re trying to track down, they’re looking at the logs they know about, they’re actually trying to be kind of DevOps-y a little bit because they have access, right? But they’re looking at it from a purely, hey, I know how this app works, I’m going to look at my logs, but I don’t really know the infrastructure. But I know this app inside and out because I’ve had to fix and maintain this damn thing for the last 6 months. Then in the meantime, over in TechOps, we’re getting alerts from Keynote or whatever, from our monitoring system. And so we’re probably more often than not troubleshooting the exact same problem independently. And so the best-case scenario is you just have some wasted time. The worst-case scenario is you actually start screwing each other up, and you end up having this scenario when if you’re not talking to each other, you really are wasting time, and you’re not getting the problem solved any faster. So I think that was, in a nutshell, a great question, and I think that’s almost a great place to start in some ways. If you are in a situation where you’re totally not doing new software innovation in your group and it’s a product that is in maintain-only mode, that’s a great candidate for a DevOps pilot because you’re talking low risk, and when you go to make these changes, these culture changes, they tend to slow you down before they speed you up, so I think that’s a great question.
Trevor: [00:23:47] Yeah, and that’s true even if you’re, you know, I’ve worked on a project where there’s actually 2 separate development teams that are working on the same kind of area, and there was an instance where somebody got a new version of the database and committed it to the branch and didn’t tell anybody. And so we load our code up, and we’re trying to see, why isn’t anything working? And, you know, at first, we thought it was just a bad merge, and it turns out we spent 2 hours tracking down a problem that we weren’t gonna fix because it was —
Matty: [00:24:25] The database was wrong. I think it’s definitely a communication story, and we like to want to solve these things, and just as much as technicians, we want to solve problems with tools. Organizations want to solve problems with concepts, right? So we’re going to say, hey, if I implement Jenkins or TeamCity or whatever properly, then it’s going to make all of these problems go away, it’s going to be a tool that’s going to save me. And then at an organizational level, you’re going to think it’s going to be this concept, what’s going to save us is open workspaces. If everybody just — get rid of the cubes, everybody sit in one big room, and then suddenly they’re going to communicate. No, it doesn’t — you can’t make somebody inherently change what they do or how they do it by changing how they sit. If you had people that didn’t want to talk to each other or communicate when they sat in cubes, taking the cube walls down is not going to magically make them talk. In fact, I —
Trevor: [00:25:25] It annoys them more often than not.
Matty: [00:25:27] They’re going to actually be madder at each other. I know, again, the organization I was at that implemented this, and then I would look at what my coworkers in other parts of the business would tweet, and it was always about how the person next to them was pissing them off because he was getting his stuff, he was crossing the line. It’s like that line in the back of the station wagon or whatever. And so kind of going off topic a little bit, but the point is you’re not going to just suddenly change because you change how people sit. You’re not going to make them communicate better. And you’re also not going to make them communicate better by sending them to some class, right? It’s part of the inherent culture and it’s part of what your model of your organization is and the personality of your organization. And that’s going to drive a lot. And it’s something I’ve been seeing, I mean, I’m doing consulting now, I see a lot of companies and we do a lot of the same stuff for them, we go in to solve a lot of the same problems, but there’s no cookie cutter to this because — and it’s not because the people that work there are so inherently different, but it’s because the personality that that organization has chosen over time to represent differs.
Trevor: [00:26:40] Several of the places that I’ve worked are kind of more hip, I would say, it’s probably not the best word for it, but it’s kind of hip. And, you know, a large majority of the clients we’ve had have been very clear-cut business, traditional, and the cultures just completely clash. And we wind up delivering products for them, but it’s just so funny. Oh guys, remember this week we’re gonna have the client in the office, so remember to dress up today.
Matty: [00:27:21] Well yeah, I have a similar thing where I barely know where I’m gonna spend my day. And I actually keep different clothes hanging in the office here, because if I know I’m gonna sit here all day long I’ll be repping the ThinkGeek nerdy shirt or whatever, but then it’s like, okay, well, you’re going to go to this client. There have been times I’ve gone out with my boss and he’s like, you know what, you really should tuck your shirt in. It’s funny. Then once you get past that, it doesn’t really matter. I don’t know why we’re talking about the clothes.
Trevor: [00:28:04] I don’t either. I forget how we got here.
Matty: [00:28:08] We just got another tweet from Nathan Harvey who says his suggestion is, you know, you don’t take down the cube walls but do go to lunch together and that you should build a relationship across teams. And I think that’s absolutely true. And the trick for that is it can’t be artificial, right? I mean, you can make people go to lunch together and I think that’s okay, but it’s sort of that stereotypical, like, okay, well, now we’re going to have the departmental meeting and someone’s going to come in and we’re going to do Myers-Briggs and we’re going to learn so much about each other. And what’s going to happen is everybody’s just going to sit around and be actually kind of pissed because you took their afternoon away and now they’re even that further behind. I’m really hoping my old boss is not listening to this podcast because I’m probably going to get a nasty note from that one. That was a little too specific about a former employer. Go ahead, Trevor.
Trevor: [00:29:06] I mean, that’s one of the things I find actually happens a lot. Where I’m at now, we have an open format. And it definitely inspires me to talk to other teams. We’ll say, oh hey, we’re going to go to Portillo’s today, who wants to come?
Matty: [00:29:25] Yeah, I think that there’s certainly places for it, and where I’m at now, our actual physical location is pretty small, it would be silly to have cubes. But I think that when you say — and also I’ve worked places where the cubes were basically mini offices, and I’ve worked places where you were still clustered together that I wouldn’t see the point of taking them down, that doesn’t make a big difference. But it’s like you said, at least be in a position when you’re — and I am a believer in getting the right people sitting near each other. I think that part makes a lot of sense. I like the idea of product teams sitting near each other and not so much because of this bonding thing or whatever, because everybody spends plenty of time with each other, but it just helps you.
Trevor: [00:30:12] It’s just a faster communication.
Matty: [00:30:14] Yeah, it’s faster communication. And where that breaks down is when you get into this whole idea if you’ve got shared resources, if you’re saying, okay, I don’t have enough testers for every product, and so I’m going to have my tester work on 2 different product teams or whatnot. But I can think of plenty of times where — and this maybe is more of an indictment of my technical skill as I became a manager back in the day — where I would be called on to do something, and you sort of do that groundhog day, and you go, hey guys, how do I do this in SharePoint again? I totally forgot how to, blah blah blah.
Trevor: [00:30:50] Absolutely. Or to get help from your team when you’re nearby, it’s just, you know, kind of incredible. I mean, it’s maybe overstating a little bit, but when you have a team where you can turn around and say, hey, I’m having a brain fart, what do I do?
Matty: [00:31:08] You know, or even when you don’t, sometimes people, and again, this is once you have that level of trust, people will tell you they’re having a problem without knowing they’re telling you. I had a sysadmin once who, we always said you had to wait for the third oh crap because that’s when you knew it was real. But you’ll do that, someone over their breath will be like, oh, this damn thing, why isn’t this — and they’re not going to send out an email saying, somebody come and help me. But you could say, that lets people know.
Trevor: [00:31:42] So I’ve got a guy I work with right now who’s like that. I can’t say what he says on the air, but it’s a catchphrase around the office.
Matty: [00:31:53] I want to figure out how — I guess they must — I always thought that, again, speaking of Food Fight Show, because I know that they say that they’re — I don’t think they’re listed as explicit in the iTunes Store, but they maybe used to bleep words out, but they sure don’t anymore. So I might want to talk to those guys and see, maybe they’ve been around long enough that Apple doesn’t notice. So maybe we need to do a bunch more podcasts before we can get all filthy. We need to do a bunch more podcasts before people want to listen to what we have to say.
Trevor: [00:32:23] But yeah, I think communication, regardless of your office layout, it’s going to be key. Obviously, it’s not explicit to DevOps, it kind of fits in anywhere where you have multiple teams working together, but it’s definitely relevant to DevOps, because whether it’s the same person not talking to the rest of the team, or it’s 2 different teams, if you’re not communicating and you’re not running things together — absolutely.
Matty: [00:32:58] So I’m thinking that we’ve clearly beaten this topic to death right now. I mean, I hope we haven’t because it’s the entire focus of our entire podcast of the future. But I think we’ve gotten our good intro, maybe given people some things to think about, about what DevOps means to us. We’d certainly love to know what it means to you. I’ve been to many, you know, there’s been plenty of places where it means different things. So I want to wrap it up here. Now this is the part in the show where we do what we call the checkout, again, shamelessly stolen from the PIX, which Food Fight Show did. Although doing a little research, it seems like they’ve shamelessly stolen a bunch of stuff from, I think, the Ruby Rogues podcast. So everybody’s stealing from everybody. This is —
Trevor: [00:33:45] I mean, isn’t that what we do anyway? Stack Overflow and —
Matty: [00:33:51] Free as beer, whichever one it is that it’s supposed to be right now. So this is part 1. Basically the idea is we’re going to tell you something that we think you should check out, something that we like. It doesn’t necessarily have to be technology related, but it’s something that we’re recommending to you, and we’ll put the information in the show notes. So I will go first. The checkout is going to sound pretty normal, but it’s topical. But if you haven’t had the opportunity to actually read the book Ender’s Game, I really think you should. I really think it’s an essential bit of reading. I have some challenges around the author, but it’s pretty classic, I think you should check it out. And I’m also going to go see the movie maybe this weekend, and I’m really excited about that. But then I can tell you next time if you should check that out. Trevor?
Trevor: [00:34:44] Well, this week, I’ll be honest, there was a Steam sale, so I’ve got a new game. I’ve been playing Saints Row IV, and it is absolutely hysterical. If you enjoy funny things, you should check it out.
Matty: [00:34:57] Okay, so I have to be kind of a little bit honest there. So I just wasn’t quite prepared, so I was spitballing on Ender’s Game, which I think will be great, but my real pick was a blended whiskey called New Campfire by High West. It’s a blend of Scotch and rye and bourbon, which I discovered — and by I discovered, I mean someone gave me some, poured me some a week ago, and it’s really delicious. So I’ll post a link to that in the show notes. That’s my real checkout, but you should read Ender’s Game. So pour yourself a nice glass of New Campfire and crack open Ender’s Game, and we will see you guys the next time around. Thanks for listening.
Trevor: [00:35:36] Take care, everybody.
Matty: [00:35:37] Okay, don’t forget to follow us on @ArrestedDevOps — oh, for crying out loud. Don’t forget to follow us on @ArrestedDevOps on Twitter. Thanks.
Trevor: [00:35:49] Bye.
Matty: [00:35:50] Bye.