Jay: [00:00:00] I would say that a lot of people I know and that I’ve met in a DevOps role prefer Chipotle as a fast food option.
Matty: [00:00:16] 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 show notes for today’s episode can be found at arresteddevops.com/punkrock. But before I introduce our guest, a word from our sponsors.
ChefConf will be held May 23rd through the 26th in Chicago. Chef has been a longtime supporter of the DevOps movement and of this podcast. ChefConf will have talks on infrastructure automation with Chef, compliance automation with Inspec, application automation with Habitat, and a ton of other relevant content. Register with the discount code ADO2018 to save 10%. Visit chefconf.com for all the details. And remember, code ADO2018 gets you 10% off the ticket price at chefconf.com.
Your application sits on layers of dynamic infrastructure and supporting services. Datadog brings you visibility into every part of your infrastructure, plus APM for monitoring your application’s performance. Dashboarding, collaboration tools, and alerts let you develop your own workflow for observability and incident response. Datadog integrates seamlessly with all of your apps and systems, from Slack to Amazon Web Services, so you can get visibility in minutes. Go to arresteddevops.com/datadog to get started with Datadog and get a free t-shirt. With full observability, distributed tracing, and customizable visualizations, Datadog is loved and trusted by thousands of enterprises, including Salesforce, PagerDuty, and Zendesk.
[00:01:58] If you haven’t tried Datadog at your company or on your side project, go to arresteddevops.com/datadog to get a free t-shirt and support Arrested DevOps. This is basically the Arrested DevOps episode that is the big dudes with tattoos and beards episode. Although we don’t have video, so you don’t, you don’t know that. But it’s happening. So, yeah, joining me is Jay Gordon from Mongo.
Jay: [00:02:23] Hey, thanks for having me. I really appreciate it. It’s really cool. I’ve been listening for a while, and obviously, I’ve gotten to know yourself, and I see Bridget all around at our various events that we attend. So, it’s really cool that I get a chance to be on. But thank you, Matt.
Matty: [00:02:44] Yeah, great. Before we kind of get into it a little bit, maybe just for listeners who haven’t come across you on the Twitterverse or the show circuit or anything, can you tell a little bit about what you do at Mongo, maybe a little bit about your background?
Jay: [00:03:00] Yeah, absolutely. So, I’m a developer advocate at MongoDB. I’ve been that for just about a year. Before that, I kind of got my start, I guess, around 2000. I started kind of kicking around some places, mostly building small little websites, then putting them on web servers and helping out a few small websites for advanced media. And then I actually got a chance at DataPipe to become a system administrator, and I worked there from about 2002 till about maybe 2010. And then I kind of moved around for a while and I was able to work at places like Courses, which was a shop that gave me a chance to meet a lot of different types of customers. I did stuff with like Hearst and some banking companies, built a lot of really cool systems on AWS. And then got a chance to go to some other really neat places like BuzzFeed. And BuzzFeed was really cool because I got a chance to see some incredibly huge scale of systems that I’ve never seen before. And that was because they had just reached new levels of traffic that websites really started to get. [00:04:00] And spent some time at DigitalOcean, got to really see some cool stuff when it came to virtualization and building even bigger hypervisors and systems and understanding hardware for those hypervisors. It was really cool. Then eventually just came over to MongoDB and it was more about finding a role that was no longer an on-call role. Started off as a TAM, a technical account manager, which gave me a place to start doing things outside of on-call systems engineering or systems administration work. And then eventually moved into developer advocacy because I really like people. So that’s the really long story of where I came from, man.
Matty: [00:05:15] Awesome. Yeah. And I think that’s one of the things that’ll be interesting to talk about, is switching from what I would call working for a living, or having a real job, to evangelism, which I’m saying with tongue pressed firmly in cheek, as developer advocates know we work just as hard as people who actually provide specific coding or ops work.
Jay: [00:05:42] It’s just different. I work with some really cool people, and one of them is this guy named Adrian Howard. He told me about something that he and Mary Thengvall, who does her own podcast about developer advocacy, talked about: how developer advocacy is kind of like the good fat on certain companies, like avocados. Certain companies need that good fat in their marketing team that can really help you get people to understand what your product’s all about. And I really ended up taking that to heart. I think that was a cool way of thinking about it.
Matty: [00:06:21] It’s super true. And I’ll try to find the link, somebody tweeted it, but remember there was that meme of what my family thinks I do, what my boss thinks I do, all the different ones for different roles? Someone posted one recently for developer advocates, and it was showing people partying all the time, and it’s basically what I do, and it’s like sleeping on a plane, or what I actually do. And I think there are certainly differences in what this role is, because we’ve talked to a lot of different people who have the title of evangelist, or DevRel, developer relations, or developer advocate, and there are similarities. But one of the things I thought was really interesting was recently there was a survey for DevRel folks kind of saying, hey, this is what developer advocacy is like in an organization. And the results were so broad, there’s very little consistency. [00:07:00] There was a discussion within a DevRel community we’re a part of where people were honestly sharing with each other, anonymously, compensation information, and it might as well not even have been listed, because it was like between $5 and $1 million. That kind of a range. The jobs are just so different.
Jay: [00:08:03] And what’s really interesting also is that none of us really have definable metrics. And that’s the really hard thing, developer advocacy is one of those things that rarely has a specific metric unless you’re with one of the biggest companies in the world, and I know one of them has a definable metric of how many people did you talk to this year for their developer advocates. That’s a really specific metric if you’re able to do a broad spectrum, get across the world, it’s like being able to have load balancers with endpoints everywhere where you never have to worry about going down. So there are just different types of metrics for systems, and there are different types of metrics for people when it comes to developer advocacy. It’s really interesting to look at both of them and try to reconcile what you think is important.
Matty: [00:09:04] And the effect of this role can be very indirect. If, in some cases, what I’d call a true developer advocate or DevRel, where you’re saying, okay, we’re trying to get development type people to use our development type platform, you have certain metrics of general success that are directly tied. You’d say, if we’re doing a good job of making developers happy, then there will be more people consuming our API, period. Those two things are kind of tightly coupled. You can somewhat connect to that, but then you can get into stuff that’s a little bit broader. [00:10:00] And I think, Jay, with MongoDB, it’s also somewhat similar to PagerDuty, where there’s not one type of person that is consuming the product. A MongoDB user could be a developer that’s writing code that’s consuming Mongo. It could be an admin, like an ops person administering a Mongo cluster. It could be an architect. There’s lots of different consumers you’re speaking to.
Jay: [00:10:25] Yeah, and I think that’s really the beauty of developer advocacy, when you’re in a role that puts you in front of so many people you probably could have worked with at some point in your career. You get an understanding of what their needs are, and you’re able to really easily provide them really important answers, because you get where they’re coming from. And I think that’s why it’s cool that developer advocacy has put me in a place where I get to meet developers, I get to meet DBAs, I get to meet people who build systems in DevOps, and it’s just a completely different kind of role than if you were traditionally handling systems all day, or handling observability, whatever it is you may be doing. It’s just a different kind of work, and I think it’s been really fun just being able to meet people and hear what they’re trying to understand or trying to do.
Matty: [00:11:29] Absolutely. And that’s where the word advocate also comes in, right? A lot of times people talk about the role of a developer advocate being to advocate for the developer inside the company as well, and be the voice of that developer. [00:12:00] And it really creates this great, what I consider kind of a full duplex connection between the user community and your product team by way of evangelism. And again, for me, I’m a DevOps evangelist, mostly in that the folks I talk to are not necessarily developers who are consuming the PagerDuty API, but working with operations teams, folks who are trying to absorb this different way of doing work, which may or may not include using PagerDuty. And that’s one of the approaches we have in our evangelism team, we want to make everybody better at how they’re handling the things our product helps you do. And we think you will do it pretty well if you use our product, but frankly you can follow our good practices whether you use our product or not. And that’s where it creates credibility, right? To say, okay, so when you say these good practices are baked into the DNA of the product, then I believe it because we know you’re good at this. You know what you’re talking about. [00:13:00] And so that’s where a lot of the conversations I’ve been having has been getting an understanding, and then also coming back to our product folks and saying, okay, I’m out there in the community having these informal conversations at open spaces or just at meetups, and these are the things people are talking about that they might not talk about in some online survey or something. And these are using different words than the words we use, let’s figure out what that means.
Jay: [00:13:36] Yeah, you know what’s interesting is, I remember when I was more of a consumer and not really quite the advocate. I remember there was a time where people would always rag on vendors. You got used to it, but you used to hear people constantly rag on vendors. And one of the coolest things I can say I’ve had, working for a company that’s a major vendor for a lot of other businesses and developers, is one day I got to do a summit where a bunch of our developers that we invited, people that use MongoDB, came to a space at one of our conferences, the day early in Chicago, and we had an open space. And from one of those open spaces, Dan Pissette, who’s our VP of Engineering, sat in on it. [00:14:00] And by the end of the open space with a group of MongoDB users, there was a PR that was getting ready to get staged. So a Jira was written, and by the end, a PR was submitted and ended up getting merged. And what I saw is true developer advocacy, is that we put people in a room and ask them, what do you want to see a part of the product changed? What do you think would help you best deploy MongoDB, use MongoDB, something like that? And we heard it directly from people who are developing, using, and engineering around it. And by the end of that session, we had something that led to a merged PR. And to me that’s a sign of success for developer advocacy, because not only are we getting people that really like our product in a room, but we also got them to tell us what didn’t work for them, and we were able to make a corrective change based on that. Just a minor, minor change, but it was something that helped that particular customer and ended up being a better portion of MongoDB. So I really get what you’re saying, and that’s one of the cooler stories I’ve heard, or at least been a part of.
Matty: [00:15:44] So one of the things, we talk about having gone from being an ops, being a sysadmin, someone like that, and then moving into more of the evangelism or advocacy role, what have been some of the challenges you’ve seen? What’s been hard about doing that? Because we’ve just been talking about why it’s awesome, it’s an awesome job, but it’s different. So what’s been hard?
Jay: [00:16:12] Maybe marketing information, starting to learn what is a brand new career, getting better at writing, especially around grammar, things that I never thought would become my career, because originally when I look at developer advocacy and I look at my career, I kind of like to think of myself as someone that was an auto mechanic for 20 years and then all of a sudden decided, let’s start a newsletter about being auto mechanics. And so now you have to kind of relearn what it is you’re going to be talking to people about. And it’s not the easiest thing. It took me a while to kind of feel comfortable in my own skin, and I’m still working at it. It’s not the easiest because you also have to go out there and be in the public and become the public face of the company you’re working for, or the project you’re advocating on behalf of. And it can be difficult and something that takes time to get used to. [00:17:00] I’m not really sure what I would call it, if it’s feeling insecure or just still dealing with the newness of no longer being strapped to a pager. But it’s definitely new. I still kind of look at my phone all the time waiting for something to come for me to do, and I realized that’s not my world. And I think that took a lot of getting used to also.
Matty: [00:17:54] Yeah, I remember that specific thing, and it wasn’t necessarily the move into evangelism, but even the move into being a solution architect, moving into sales engineering. But moving from being in an on-call type situation was the first time I realized it was okay to leave my phone on a different floor of my house.
Jay: [00:18:14] Being on call can be traumatic and dramatic. It doesn’t have to be, and we all know that, but if you struggled through periods of time when people weren’t quite doing work the right way, and whatever the right way is, it’s certainly not the way I think I did some of the work earlier in my career, where a lot of that stuff was siloed and it was more like, hey, what’s down? Okay, let’s figure it out. [00:19:00] It took a while to no longer have that mentality of, my phone is going to go off at some point, and someone is going to get disturbed. So I think it just took a little bit of getting used to.
Matty: [00:19:00] I remember a great anecdotal story from Nathan Harvey. He was, again, Nathan, before he became the Chief Awesome Officer of Chef, Mr. Community and everything, he used to work for a living too. And he and I have talked before about this exact thing, about how hard it is. It’s like the phantom limb, the phantom buzzing. And he was going on a vacation with his family, and he told his wife he was going to leave his laptop at home. But he said until they were on the airplane he couldn’t tell her, because he wasn’t sure he could do it yet. But he left his phone at home. And that was the thing, his wife has her phone, the whole family, anybody in their extended family knows how to get a hold of them through there. But it was such a tough thing. And I, this past summer, we went with my family up to northern Minnesota, and I didn’t leave my phone at home, but I left it off. [00:20:00] I left it in our lodge, basically turned off, so that once a day we’d come back there and could turn it on and the kids could FaceTime back to their mom and do whatever. But it was just nice to not have it and be disconnected. And I especially removed my work email. I literally uninstalled Slack and all those things from that phone so I wasn’t tempted, because no matter what you try, you still are like, well, let me just duck in. And it’s hard to realize that, you know what, there’s no such thing as a developer advocacy emergency.
Jay: [00:20:45] Yeah. I mean, what happened? Did a blog not go out at the right, or the wrong time? Who knows? There are things that are actually time-sensitive in the work that we do, and that goes without saying, everybody’s got deadlines. But at the same time, I feel like a developer advocate is capable of taking that kind of time off. And you know what, I think that one day I’ll learn to have that unplug skill. I’m still kind of trying to work my way out of what my previous career was into the role I’m in now, that maybe one day I’ll feel able to do what you’re doing. And I think it just comes with some maturity, and also with just the available free time during your time off to accept you could put your phone down and not care about it.
Matty: [00:21:40] You just have to do it. It’s a muscle that you have to exercise. And it’s the first time, it’s scary as shit, but then you survive it and you go, oh, that was no big deal, and maybe that was actually kind of awesome. And the other thing is, to your point, you have to be ready for it. So you have to sit and say, okay, I know this is coming, I’m taking a week off and I’m going to spend time with my family, or by myself. [00:22:00] One of the things I’ve said for years I want to do, and maybe I’ll eventually do it, is I want to take a weekend and go camping, not necessarily anywhere crazy in the middle of nowhere, it could be just some forest preserve, and I’m going to leave my phone in my car. And once a day I’ll go check it, make sure I don’t have a voicemail from my kid’s mom or my wife, make sure nobody got hurt or something like that, and just intentionally be disconnected. And I think when you’re prepared for that and you know what’s happening, you can then not stress out about what you’re not getting done, because you’re able to be ready. And that’s one of the things that was really helpful to me when I took that week up north this summer, I knew it was coming. I had to prepare so that I wasn’t there at the 11th hour going, oh shit, because the last thing you want is to be in a situation where you know you’re going to come back and now you’ve got a week’s worth of work to catch up on because you were gone for a week.
Jay: [00:23:17] Sure. And I put so much pressure on myself sometimes for vacation, where I’ll try to get all these things done before, so that when I get back I don’t have to worry about it, when I know it’s not really true. The work is going to be there no matter what, so just chill out, relax, and do what you got to do. Enjoy yourself is the way I’m trying to feel about it.
Matty: [00:23:40] And make sure it’s either in a completed state before you leave, or it’s going to be in a starting state when you get back. You know, because we know it’s coming, it’s a big difference from if all of a sudden you get the flu and you’re out for a few days. But when your vacation’s coming, you can plan for it. You can say, I’m going to ease up to it so I’m not taking on a big thing right before, so I can be in a good stopping place. [00:24:00] And one of the things I learned from my coworker Kevin Chef was super true, and it’s funny because I just listened to an episode we recorded at DevOps Days Chicago back in August we just released, and the cold open was Katie Prizzy saying, it’s not like you can come back from vacation and just delete all the emails that accumulated while you’re gone. And I said, sure you can. And you know what, that’s what my coworker Kevin does. He does email and Slack bankruptcy. He’s like, you know what, if it was important, you’re going to reach out to me again.
Jay: [00:24:43] That’s a tough move to pull at some places, because you know you’re going to have somebody definitely hard-ass you on it in response, and it won’t be the easiest response. Especially, I guess it’s right place and right situation, yeah, you can maybe get away with that.
Matty: [00:25:05] One of the things I’ve always been a believer in, and I wish I could remember where I heard this first, it was in one of the various time management blogs, podcasts, but you have to train the system. A good example is when people say, I’m only going to check my email once a day, that’s actually a fine thing to do. What you can’t do is have been in a position of checking your email and responding immediately for years within your company, and then suddenly just decide to check it once a day and not tell anybody. So you have to set expectations. [00:26:00] You say things to your team, here’s how I’m going to start working now, so you know. And maybe it’s going to be a little tough for a while, so let’s work through it. But you can expect I’m going to check my email once a day and this is when I’m going to do it. And this is kind of how I look at it, because I try to be that person, I try to not check my email all the time, but my close coworkers know if you need me in a time-critical way, text me, that’s the way to get a hold of me quickly, because you’re not going to do that for something that’s not time-critical. So you still have an ability to do that. Then the same thing, you can go to the people you work with and say, okay, I’m going on a vacation, and any communication that comes into me while I’m gone is going to be basically automatically deleted. Maybe you put that in your autoresponder, I am not, your email is actually not going to be read when I get back, email me when I get back if it’s important, or maybe you start with just Slack bankruptcy at first. [00:27:00] And you have to force yourself to do that and say when you come back from a week’s vacation to not want to go back and catch up on all the channels and all the stuff you missed. Because it’s sort of like when we all got TiVo at first, and TiVo would automatically record stuff for you, and I don’t know about you, but I felt like I had to watch every single thing, and I didn’t see the sun for a month and a half. And then it was like, wait a minute, because when you’re shifting, because it used to be that if you recorded something with your VCR, it was because you wanted to watch that specific thing, so it was much more deliberate. And now in the days of DVR and on-demand and everything, we just have this big smorgasbord, but we change how we think about it. And I think that’s the case with things like Slack, we have to learn so that they’re not so obtrusive to us. It just has to be in the moment. And if you’re gone, then you’re gone, and if it’s important, someone cares enough. [00:28:00] Now, again, there’s a huge amount of privilege with what I’m saying, you have to be a certain, not everybody in an organization can get away with that. You might not be able to get away with Slack bankruptcy from a DM from your boss, maybe you check those. But it’s about setting expectations. It’s not fair to change the way you’re going to work without enabling the people that are important to you, or that you’re important to, to know how to do it. But people will usually adjust if you tell them how to do it.
Jay: [00:28:28] Sure. I mean, we always say that DevOps, one of the big portions of the concept of DevOps, is communication, and modifying the way you communicate without actually informing your team that you’re going to be modifying that method of communications is actually kind of the antithesis of being part of a DevOps-y kind of environment.
Matty: [00:28:50] I was going to say it’s a dick move, but that’s basically the same thing. Yeah, dick move, antithesis of DevOps, dick move, about the same thing.
Jay: [00:29:00] You know, it depends on what room you’re in at the time. Now, if we’re talking about dick moves, I’ve actually got a dick move. I mean, it’s not as much of a dick move as it is something that really kind of shitty that happened recently, and it was a topic I kind of wanted to discuss with you today because I wanted to get your thoughts on it as well. So there was this Memcached thing that happened to GitHub. [00:30:00] And I thought about some stuff that made me really understand what the true impact of the Memcached exploit was. Think about what GitHub is to businesses, then think about what it is to teams, then what it is to developers, then what it is to students, and then what it is to kids who are just learning how to start using any type of code. So I put that all into perspective, and I thought, geez, what a frigging terrible exploit to hit one of the most important parts of a lot of people’s businesses right now. So it was troubling, if anything else.
Matty: [00:30:14] So just to look at that and say, okay, so basically to attack GitHub for the lols, because that’s basically what this was about, to prove a point, is just not the better part of valor, there’s limits to script kiddie attacks, they should know better. Is that what you’re getting at, or are you just sort of saying—
Jay: [00:30:44] I don’t know that. I just thought about how deep the impact was, and how many individual businesses and companies, projects, and everything down to educational purposes, were all impacted. And obviously there are people with private repo services and private Git, like GitLab and stuff like that. But think about just the extent of GitHub in our world, whether you’re a developer, whether you’re a person building systems automation code and storing it in GitHub as part of some sort of CI or CD process. It’s just amazing to me how deep this exploit went. [00:31:00] And what it really comes down to is that Memcached, while it’s really super easy, it’s like a dumb protocol, and you can throw anything in it, and you can exploit the hell out of it, and it was proven. It was just kind of amazing to me that there were that many people who still just weren’t firewalling systems, and the providers out there weren’t doing default-to-block ports. And I think that to me was the more troubling portion of it than anything else.
Matty: [00:32:02] So I guess maybe we can give a little bit of background on what happened, because I’m thinking about, you’re right, the impact of any outage on GitHub, as we know, it’s like when GitHub is down, everybody stops being able to work. It was pretty much almost exactly a year ago when there was the S3 outage in US East, which took down GitHub, and everybody went, well, I don’t know what the fuck to do now, I guess I’ll sit and play some Nintendo Switch. Well, except they couldn’t, because it wasn’t out yet.
Jay: [00:32:35] It could be down, but we’ve become so much more closely coupled with what we do and how we do it. The impact to one service really does start to spiral very quickly. We saw it with that, we saw it when us-east-1 has an issue, and then the S3 outage, obviously. And I remember there was a DNS issue from Akamai where somebody sent out a wrong announcement for a bad route, it took down a lot of shit. [00:33:00] It’s just amazing the level of interconnectedness around everything we have now, because we’ve moved everything to service-based architecture. So it’s just amazing to think about it. And the Memcached thing, I’m referring to the 1.7 terabyte DDoS attack that came from all these UDP reflections. It’s just amazing to me that people also didn’t realize they were probably part of something really, really bad, and they just never took care of it. I worked at some tiny providers in the past where core routers would show floods, and we’d go in and find someone installed some nasty script, or found 777 on a shitty directory that was able to inject some sort of port flutter. But it’s just gotten so much more intense with the advent of cloud systems, and there are still a bunch of providers out there that aren’t blocking ports by default, and I think that’s going to create more of this kind of mayhem.
Matty: [00:34:30] Yeah, it’s becoming too easy to spin up machines that don’t have any type of protection. And I guess in some ways it’s frustrating, because you have to explicitly go out of your way to remove this protection. You’re going to spin up an EC2 instance, it’s not going to have those ports available, but you’re going to sit there and be the lazy ass that goes, well, I can’t figure out what ports I need, so all of them, right?
Jay: [00:35:06] And that’s the shitty part about the lazy developer, and I don’t want to just say developers, but the lazy person using a cloud system, is that they don’t think about the repercussions of their actions, because it’s not just—
Matty: [00:35:21] It’s not just your system, right? It’s like, oh well, who cares, this is just my little dev box, I don’t care if somebody hacks it, but somebody hacking it is actually impacting other people. And it’s the not realizing that all of these things are just the beginning of the conversation. I get this all the time talking to your relatives about technology on Facebook, anytime I go in there and say, you absolutely need to 2-factor up your Facebook login, well, I don’t care if somebody logs into my Facebook, who gives a shit. Well, except now they have the keys to your entire kingdom, because OAuth is a total thing. [00:36:00] And people aren’t trying to hack your Facebook so they can post things on your wall, they’re trying to hack your Facebook so they can log in via Facebook’s OAuth provider into your bank or your email. So it’s hard to see that it’s just the beginning, like you said, it’s a beginning step. By not protecting this small thing here, you’re compromising millions of your neighbors.
Jay: [00:36:32] Well, a lot of businesses like to think that fast and loose early on makes sense, or projects, or startups, they think fast and loose, let’s get it done. But you start to learn, what’s the old joke of the unicorn shitting rainbows while people in the sec section have to clean up. And it’s kind of true, because there’s these idyllic visions of where systems automation is and how quickly you can produce and change and deploy, and that makes a lot of sense. [00:37:00] But someone kind of gets left behind when you’re fast and loose about it, and a lot of companies end up getting in that place, I’ve seen it before myself. And when it comes home to roost, it’s nasty. I know of a place that had a really sensitive system get compromised because somebody was fast and loose with an SSH key. And you start to learn that your secrets are important, and maybe your ports are important, or what interfaces services run on are important. I think it’s just the thing you have to learn from failure, and failure is a great teacher.
Matty: [00:37:59] I’ve always said that if people are afraid of being punished for making a mistake, they’re not going to make fewer mistakes, they’re just going to become really good at hiding them. And now you’re completely fucked, because you don’t know about those keys that leaked. Someone leaks a key and goes, okay, oops, I just did that, well, I can tell somebody and we can fix it. Oh, but if I do that, I might go on the shit list and get put on a performance plan, so maybe what I’ll do is see if I can really quick undo this before anybody notices. [00:38:00] And now we’ve left this gaping hole open, versus being able to safely say, okay, we have a problem, let’s get all hands on deck and staunch this bleeding and be in front of it. And that’s not bullshit.
Jay: [00:38:48] No, you have to be responsible. I’ve taken down one of the major websites for a company I worked for, I took it down, it was my fault, I made a mistake, but the thing I did was I didn’t hide it. And maybe that came with seniority and me not fearing that, and that is a certain level of privilege that comes with being at places for a long time. [00:39:00] If you’re honest and say, look, I was trying to delete this system and that system got deleted by accident and it restarted something, I’m going to get it fixed, but this was my fault and I’m going to fix it, but I found a flaw and I’m going to fix that too. And I think sometimes it’s more important to find what was broken and fix that, and admit to the problem that maybe came out as a result, than just hiding the fact that there’s a problem.
Matty: [00:39:40] Well, the thing is, you said because based on seniority you feel more comfortable not hiding things, that is completely telegraphed by previous experience. You can’t be a super brand new person, because you don’t know, but it’s all about how, as leaders in an organization, whether it’s literal management or just the more senior people, set that expectation. [00:40:00] Even things like not literal punishment, but if you make fun of somebody in Slack for making a mistake who’s more junior, that sends a message that says don’t admit to mistakes because people will make fun of you.
Jay: [00:40:21] Doesn’t work like that anymore. When I was young, I saw a lot of that shit, we would all be in IRC, somebody would say, oh, look at that ticket, you did the wrong thing, you fucked up, blah blah blah. But in the end, when I got older, I started recognizing that’s completely counterproductive.
Matty: [00:40:40] And it’s tricky, because here’s one of the things I realized, and someone had to point this out to me, and thank goodness they did. A couple years ago I was in HipChat or Slack or whatever at Chef, and my good buddy Sean, who I have tons of respect for, we’re very good friends, he sang at my wedding, was trying to figure out something with Knife Bootstrap and capital P versus lowercase p, and he’s like, I don’t know why it’s not working, and I was like, oh, you big dummy, how do you even DevOps if you’re not literate. [00:41:00] And somebody pulled me aside in private message and said, that’s really not a good idea. And I was like, oh, he knows I’m kidding. And they’re like, new people to the team don’t, junior people don’t, all they saw was Sean had a problem and asshole Matt made fun of him, they don’t know that Sean didn’t have his feelings hurt and that’s just how you guys joke around, and we just have to remember that’s a privilege to be able to do that, and we are setting examples, and as much as we want to kind of pull the Shaq, I don’t want to be a role model, sorry not sorry, you are, as a more experienced member of your team, and you’re setting an example. So be the change you want to see in your DevOps world, I guess. So this is random, I don’t really quite know what this is supposed to mean, but Michael Roberts asked us to talk about the role of fast food in DevOps, and I want to see how we’re going to tackle this. Hmm, I don’t really know, there’s got to be an analogy somewhere.
Jay: [00:42:27] I mean, the analogy is what everyone will do, because based on every conference I’ve ever been to, every single possible topic you can think of is comparable to DevOps. So I guess fast food is like DevOps, but if I really think about the role in DevOps, I would say that a lot of people I know and that I’ve met in a DevOps role prefer Chipotle as a fast food option.
Matty: [00:42:58] Oh, I can’t. You know what, maybe I’m in the wrong business, because I just do not care for Chipotle. I think it’s because I don’t like cilantro and there’s just too much cilantro-based options at Chipotle. I would think the most DevOps fast food is probably In-N-Out, because it’s very simple and there are tons and tons of hacks, but they only adjust for you, right? There’s not the best practice, there’s just the basics, and you got to figure out how to take those basics and adjust them. You’re not going to cargo cult, you might have your way you like to order it, and if I just say, well, I’m just going to get what Jay likes, I’m probably not going to like it without considering what’s right for me.
Jay: [00:43:53] Double-double animal style is kind of the way I go, but that’s because I’m from the East Coast, and when I go there I get the hipstery whatever is popular with the kids, and I always hear it’s double-double animal style, then I go with fries well done and tons of salt. But you know what’s funny is we are the big guys with tattoos, so why not talk about food. The cool thing about working in New York City, and I’ve kind of been a New York lifer, I worked basically here in New York City and New Jersey for pretty much my whole career, and the best part about these cities is, and I live in Manhattan, is the fact that you’re not stuck with just fast food. [00:44:00] Central Jersey was a little tough, a lot of fast food, a few great delis, and that’s the thing, for all my New Jersey listeners and people from the area, when you find a good deli in the New Jersey area or New York City for that matter, you hold on tight, we are really specific about our delis. And I think the fact that New York City gives you that availability of eating whatever you want, so I think fast food might not play as close a role in DevOps in New York City as it would other places, just because we have limitless options here, it seems.
Matty: [00:45:24] But I love New York, always, and I can’t wait, my kids haven’t been, we’re going to figure out a time to get them to go when they can appreciate it. But a lot of what they’re going to need to be able to appreciate is the food, right, and to me it’s like a bodega, or getting the thing I loved, like I could go into a deli, go into a bodega at 4 in the morning and get a bagel with turkey on it in the middle of the night.
Jay: [00:45:53] Right.
Matty: [00:45:54] And it was just like, it’s just whatever, it’s just always going.
Jay: [00:45:57] You know, I will say I’ve walked out of 111 8th Avenue, which is a data center here on the west side of Manhattan that I’ve worked in and out of probably most of my career, and going and walking down the block to find a deli to get a turkey on a roll to get me through the night.
Matty: [00:46:22] Just to wrap up, because we did promise, I called this episode Punk Rock DevOps, and mostly it was because you talk about Fugazi a lot on Facebook. Well, so what I was thinking would be cool is to talk a little bit about a quick reco, if you want to set up your little DevOps coding, if you’re going to do some DevOpsing and you want to build a little punk metal rock playlist based on your recommendations and mine, maybe throw like 6 or 7 tracks at them that you’d recommend. I’ll throw a couple that I think, and we could do this thing and maybe people create a Spotify playlist and it’ll be famous.
Jay: [00:46:58] So I’ll tell you some of the stuff I listened to today. So today I listened to Void, the old Discord DC hardcore band, there’s the Faith Void split, listen to the Void side, it’s a great, great record, I love it. Listen to a bunch of Fugazi because I’ve been in a really big Fugazi mood lately. Check out the track, there’s so many good ones, Cassavetes, check out the song Cassavetes from In on the Kill Taker. What, just a tremendous song. What do you got?
Matty: [00:47:40] So a couple of things that have been on my playlist, I have a playlist I call coding music that I’ve been listening to lately when I’m writing code. I’ve got Rise Above by Black Flag.
Jay: [00:47:50] Great.
Matty: [00:47:51] Is on there. Last Caress by Misfits, love it. Straight Edge by Minor Threat.
Jay: [00:47:56] A favorite.
Matty: [00:47:57] Nervous Breakdown by Black Flag.
Jay: [00:47:59] Love it.
Matty: [00:47:59] Holiday in Cambodia, Dead Kennedys. And you got to throw in a little bit of Slayer, so I put in probably Raining Blood, and just for fun, a little L7, or a little Social D, so maybe throw in Highway 101 just to lighten the mood a little bit, Highway 101 by Social Distortion would be what I’d put on there.
Jay: [00:48:22] So I got a cool little playlist I built recently with a couple people from, so a bunch of us at MongoDB started a Slack channel for metal, because we’ve got a nice culture of metalheads in the company, and we kind of started to spot each other, and once you spot other metalheads, especially once you get into a larger company, because Mongo’s, we’re big, not huge, but bigger than a small business, so we’re all over the world. [00:49:00] And so you get to meet people who like the same kind of music. So some songs I put in a playlist with a few other people are Wolverine Blues by Entombed, I love that friggin song, Heartwork by Carcass, another great one, one of my coworkers put in Funeralopolis by Electric Wizard, great track, especially if you got some really slow processes going on, you’re going to be waiting for a while, but if you need something really fast, put on some Nails. My buddy Leon has been playing guitar in Nails for about a year or so, and Leon has actually been one of the longest system administrators and people I know, he’s been in death metal and hardcore bands for as long as I know, and I think he’s been working at DreamHost now for over 10 years. [00:50:00] Really, really awesome dude who loves metal and has thrown Linux CDs at my head, it’s cool when you find out there are nerds in bands, there are a lot of nerdy bands out there too. Check out some of the new Morbid Angel, Piles of Little Arms by Morbid Angel is a really great newer track, Snapcase is going to do some shows in New York, so I threw on Caboose by Snapcase, and then I’ve been listening to a lot of old DC hardcore, so the Flex Your Head compilation always does it for me.
Matty: [00:50:31] Excellent. So yeah, we all put this playlist ideas in the show notes so you can find it at arresteddevops.com/punkrock. This was a great conversation.
Jay: [00:50:41] I enjoyed it.
Matty: [00:50:42] Yeah, I don’t think we had any idea where we were going with it at first, or when we wanted to do it, we just knew we wanted to have a good time. So we did.
Jay: [00:50:49] Well, it reminds me almost of the first time we met, just to give everybody a quick, so we had been introduced, I think it was by Nathan as we mentioned earlier, from Chef when you were working there, and I needed to interview somebody in Chicago for MongoDB, I just said, hey, you look like a person that wants to talk to me, I look like a person who wants to talk to you, and we just kind of hit it off, and it’s been cool getting to know you. So thank you very much for having me part of this.
Matty: [00:51:20] Where are you going to be coming up? I am going to be speaking at the DevOps meetup in Minneapolis next week on March 20th. And then I’ll be home for a little bit for spring break with the kids. April’s kind of busy, I’m going to be speaking at DrupalCon in Nashville, at DevOps Days Des Moines, and then back here at home at GOTO Chicago. If you go to mattstratton.com/speaking, you can see when I’ll be coming to a meetup or conference near you.
Jay: [00:51:50] I got a few DevOps Days coming up. I’ll be at DevOps Days Rocky Mountains, out in Denver, Colorado, I’m really looking forward to seeing Jason Hand and all those really cool people out there. And then I’ll be at DevOps Days Silicon Valley later, where Jennifer and the rest of the cool folks at Chef are going to be hanging out in that super awesome computer museum. So I’m looking forward to seeing everybody there. And I think I’ll be out in Chicago also, and I’ll be at your DevOps Days out there, very much hoping to get to it this year.
Matty: [00:52:25] Yeah, so we should be opening the CFP for DevOps and the registration for DevOps Days Chicago, I believe we’re hoping to open that on Monday, March 19th, I just went and actually we set up all the Eventbrite and all the paper call stuff today, we just haven’t turned it on. And I’m going to try to get to DevOps Days Rockies, it’s one of my favorite events, I’m just not, haven’t figured out if that’s happening or not, but I’m going to try to move heaven and earth to get that to go. Speaking of DevOps Days, the discount code ADO2018 will probably get you 20% off when you register at one of them. It will definitely get you 10% off of ChefConf, and it will definitely get you 5% off of GopherCon.
Jay: [00:53:08] I got one of those. Excuse me. And if you’re interested, check out MongoDB World, we’re going to be having MongoDB World in New York City in June. If you’d like 25% off a ticket, just use Jay Gordon, that is J-A-Y G-O-R-D-O-N. And if you need more information on MongoDB World, you could find me at any time on Twitter, it’s Jay Destro, and literally almost any time, @JayDestro, you can find me on Twitter pretty easily.
Matty: [00:53:38] It’s super true. I’ve had a couple of conversations with Jay where he’s like, man, I’m just signing off for the weekend, done with the internet, and then a day later it’s like I’m going to DM him and he’s like, okay, let’s talk about this thing. So, you know, we’re going to work on the work-life balance.
Jay: [00:53:53] Highly online, just highly online, extremely logged on.
Matty: [00:53:58] Yes. A couple things to check out that I wanted to share with y’all. One kind of cool app is called Muzzle, if you go to muzzleapp.com, it’s a super simple little Mac app, it turns off notifications when you’re screen sharing. This is really helpful if you’re the kind of demoing kind of person. And the other one I like is an iOS app called Tailor, T-A-I-L-O-R, and what it does is it automatically detects overlapping screenshots and merges them into one big one. [00:54:00] The most useful use for that was when me and Paul Zarkowski and Michael Ducey were trying to figure out 2 or 3 days in a row that we’d be able to get together to go to a bunch of meetups, and it was a text conversation that started with us looking at dates in February and going all the way to September, it was a giant long text thread, and I was able to make it into one image, so it was useful for that. So Jay, thanks for being on the podcast, I had a lot of fun, I’m glad we got you on the show. If you go to arresteddevops.com/punkrock, you can get all of this episode’s show notes, and their website also has our newsletter, the Patreon, all the Arrested DevOps stuff you could ever want. If you go to arresteddevops.com/itunes, leave us a review in the iTunes store, that helps other people find the podcast. [00:55:00] Little tricksy update I just made the other day, you may notice in your podcatcher that the show notes actually show up now, at least they will if you’re using the Apple Podcast app or Overcast. Let me know if they aren’t showing up in your app, because I haven’t tested any other. I’m Matt, @MattStratton.
Jay: [00:55:34] We’re Arrested DevOps. And remember, there’s always DevOps in the banana stand.
