Matty: [00:00:00] I used to say that I had a lot of respect for MCSEs until I became one. 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 Matty Stratton, and joining me today is, for the second time on the show, is Jay Gordon. Hey! Hey, Jay, before we get into it though, let’s have a word from our sponsors. Chef is a community of professionals practicing DevOps every day. We are making, proving, learning, and shaping the future. We are known for welcoming, encouraging, and liberating others to do the same. We do not talk about change, we do change. Join the community and learn about our solutions at chef.io. 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 arrestedevops.com/datadog. The worst time to learn about incident response is during an incident. Don’t wait for an outage to strike before getting started. The PagerDuty Incident Response Training Course is now open source and free for everyone at response pagerduty.com. Based on the same training that PagerDuty employees go through, this course will show you how to streamline your incident response process, turn chaos into calm, and demonstrate the role of an incident commander. So what are you waiting for? Go to response pagerduty.com today and check it out.
[00:01:52] The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next. What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting? But fear not, dear listener, there is a solution. You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed. What are you waiting for? Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app. Looking for an opportunity to accelerate the delivery of reliable, secure software applications? Agile+ DevOps West brings together practitioners seeking how to leverage Agile and DevOps concepts to bring cross-functional teams together to deliver software with greater speed and agility while meeting quality and security demands. Learn from industry experts at Agile+ DevOps West. This June in Las Vegas and get started on the path to reduce lead time and successfully deliver stable new features. Arrested DevOps listeners use code AD400 to receive $400 off their conference registration fee. Learn more at arresteddevops.com/agiledevopswest.
[00:03:30] Jay was on the show just about a year ago. We were talking about making the journey from ops to advocacy and punk rock and metal and the link If you want to check that show out, go to arresteddevops.com/punkrockdevops, I think it is. We’ll put a link in the show notes. Sounds about right. Punkrock DevOps. You can find it. But so today, it’s a— I’m sitting here in Chicago. It’s a little chilly and thought that there’d be a good time for Jay and I to get together and talk about things that we’ve been thinking about and what’s been going on in the world of careers especially.
Jay: You know, it’s interesting. I’ve had kind of a standing one-on-one with someone that I don’t work with, and I really believe in the power of it. It’s someone that I’ve kind of like built a mentor relationship with. Mentor— I’m the mentee in the relationship. But, you know, I love having conversations with other people who are kind of like in our world, whether it’s technology or maybe advocacy, and I just like chatting. So I appreciate you giving me a chance to chat with someone as usual.
Matty: [00:04:44] So basically, listeners, you get to eavesdrop on our Zoom coffee, as Emily likes to call them. Emily Freeman refers to them as Zoom coffees. I don’t know if she invented that term or not, but we’ll pretend that maybe she did. So Jay, you were telling me before we started recording that you have recently achieved a certification of some sort. Let’s talk about certification. Talk about yours, first of all.
Jay: Yeah, not much of a certification, but here’s the thing. I work at Microsoft, and I’m supposed to be advocating for the Azure product, and I’m supposed to be reaching a particular audience, and of that audience, I need to actually be able to speak to them, not just about technology that I’m already familiar with, like, yeah, I understand DevOps practices, I can talk to you about Chef, Puppet, Ansible, all those things, But the thing is, is that I work for Microsoft. I’m talking about Azure. And ultimately, I’ve decided I wanted to find a new way to learn. And so I thought back to the ways I used to learn when I was really young. When I got into technology, I didn’t come from an internship or college or anything. So I kind of had to go from the certifications as a way to justify your work, which was the model back then. And that model has really moved on. But the one thing that I found about some of these exams is that there are actually a good baseline to give you some information about what you actually may or may not know about the subject. So I just wanted to learn more about, like, aside from the technology, I wanted to learn more about offerings. I wanted to learn about governance on the cloud. I wanted to learn about the big picture stuff of when you’re moving a business from, say, one spot to the other and how to actually tell people, you know, this is how to establish a subscription, how to establish business units within the subscription that all have their own accounts. So I spent time to learn that, and I got certified on that because I wanted to take a test that said, yes, you know this. And so, uh, I, I, we touched on it for a brief second about you had feels on certs. And my whole feeling is, is that I like them as a way to do some self-check. I don’t like them as a way to justify whether or not you really do know something.
Matty: [00:07:12] I’ve— what I found, so most of my experience with certifications is pretty old school Microsoft. I was exiting the NetWare world right around the time that it was hot. So I never got— I was never a CNE. I was never NetWare certified. Although I thought about it. But what had happened is I started early in my career, when I was first getting into the Microsoft side of the world. So just a little bit of background. So I don’t know, I never ran DOS. The first Windows I ever really touched was Windows 95, and then I supported Windows for Workgroups after that. So I don’t know a lot. I always was running Unix, working in the Unix lab in college, and always had Apple computers before that. But I was doing, uh, the way I got into the Microsoft world was I was doing field service for a lot of prepress shops. So I was an Apple field service technician, and prepress shops, they would be running Macs on the design stations, but then they would have these stations that ran the printers. They were called RIP stations, and they were all running NT 3.51. So I had to learn. So I learned NT, and from that I got a job at a systems integrator. And one of the requirements of the job, because the company wanted to be able to say X number of our people are certified was within 60 days or something like that, I had to be a Microsoft Certified Professional, which at the time meant you passed one exam, you know, so I took the MC4 exam, right, and was an MCP. It was really— actually, the funny thing was, so this is— I’ll tell you, this is going to devolve into some stories about taking tests, but they’re always kind of funny, is I took the exam and I was so excited to find out how I did that I kind of blew through it, answered the questions, and I missed passing by one question. And I was able to reschedule the exam for the next week and then was able to, you know, and that’s when I developed a little bit of my practice, which doesn’t work in current exams because they’re modular or they’re adaptive and everything. But back in those days, there’d be X amount of questions and you could go through them and you would be able to mark a question. And I would mark questions that I felt I was 100% sure I got right. And I would calculate what was a passing score. You know, I’d say, okay, I know I have to get this many questions right. And I would continue to loop through until I had marked enough that I felt I passed it. And that was simply a method of making me think, think my way through the exam. So I passed that and I was excited. And then this was also, they had introduced, Microsoft had a new certification Where if you, in addition to some of their products, if you were certified on either IIS or Internet Explorer, you would get what was called +I certification, which meant plus internet. So I was an MCP +I, and there weren’t a whole lot of us, but I was one of them. And when I left that job, I went to work for a consulting company that paid for all of our exams, pass or fail. And so then I was going after my MCSE, which is, at the time, there were 2 Microsoft certs. There was MCP and then Microsoft Certified Systems Engineer. And I really believed that was gonna be my holy grail of certification. Like, I had so much respect for MCSEs. And I used to say that I had a lot of respect for MCSEs until I became one.
Jay: [00:10:39] Yeah, and it was what, like 6 or 7 exams?
Matty: It was 6 exams. And the only exam I had to take twice was Networking Essentials because Networking Essentials had a slightly higher passing score than any of the other exams. And when I applied my little algorithm to it, I missed by one question. I do remember having a guy I worked with who was the head of internet security for the insurance company that I was working with at the time, and he had the notable achievement of passing all of his MCSE exams in one day. He basically scheduled them all up in one day, decided he just wanted to see if he could do it, and he did. He did. And since then, I’ve gone through the— I’ve become an MCSE under Windows 2000 again through the time, you know, I’ve updated my Microsoft certs. I think the last certification I was certified on was 2003 on the Microsoft side. But it became a point when I was a manager when— because there’s some deal when if you go to what used to be called TechEd, which I don’t know what the equivalent is now. It’s Build has become kind of— and whatever. There used to be a conference called TechEd, which was the big conference for IT pros, and you could take Microsoft exams there at a discount. And my senior sysadmin that worked for me was going to take a bunch of exams. And I was— I decided that there was no way I could let him have more certifications than me. So we had a little gentleman’s bet on who could pass more exams. And, uh, I did. He, of course, this goes to reflect on how valuable the exams are because he is a much better systems engineer than I am, but I guess I’m better at taking tests.
Jay: [00:12:24] You know what it really came down to? And this is the way I looked at this old kind of model. That we all worked with, and I say we, I really think about the people who worked from maybe like ’99 to about maybe 2006. Like there’s this weird period between ’99 and ’06 where a bunch of IT recruiters really did believe that certifications were like the bellwether of whether or not you were a good technologist. And I think that that eventually changed a lot with the coding interview, the FizzBuzz, things like that. And so I just thought about how a better portion of that was all about memorization. And while I passed tests, in the end, I don’t know if I learned a lot. I just memorized a lot of stuff.
Matty: The tricky thing about those exams, and also Cisco Certified, Now, I never got my CCIE. That’s a certification I still maintain a lot of respect for because that’s a rough one. But what I found when I was going through my Cisco certification, and the Microsoft certs were similar to this as well, is it wasn’t just about knowing the right answer, but it was about knowing the way that that vendor wanted you to answer the question. So there would definitely be cases where there’d be multiple correct answers, but what was the Microsoft way? And because in a way, when you’re getting certified by that vendor, they were putting their stamp of approval on you that said you, you were in a way representing them. Yeah. Well, yeah, yeah. And so it was, it was a lot of memorization. It was a lot of learning the right kind of answer, which is why it was hard to take those exams cold because you could know the technology. But if you didn’t know, if you didn’t follow the study guides, you might not necessarily know how they wanted you to answer it. I wanted to kind of go back when you were talking about how we were coming up with certs. So for me, they were really essential for my career because I don’t have a college degree. And so when I was starting out in my career, I needed something as, you know, in lieu of— I had some experience, but I needed something that gave me at least— it gave a little bit of probably reassurance to a hiring manager that I kind of knew something, right? It didn’t mean that I was a super expert, but it was a credential of some kind.
Jay: [00:14:54] Yeah, it was, it was nice to be able to walk into certain interviews with the, hey, you know, I took these tests, I passed them, and based on that, companies X, Y, and Z all think that I know enough about the subject matter that you want to hire me for. And so that’s the way it kind of was until It became not necessarily the best model because I think a lot of people, and especially in the hiring world, started recognizing that just because you, you’re memorizing some things didn’t necessarily mean that in the real world and practice that you were going to have the experience. And that was kind of the weird folly of these certs is that a lot— there were a lot of companies that were like for-profit education that came out to people and said, you know what, you take these certs, you’re going to get hired day one. And it wasn’t true.
Matty: I think certifications have matured as well. A lot of the exams have become more practical. So, and I look at that and I think about ones that I’ve had, and that was like I alluded to, like the CCIE. So the CCIE requires a lot of hands-on lab work in addition to just a multiple guess exam. And for example, I helped test, and I was one of— if I wasn’t the very first, I was one of the first 2 or 3 Chef Certified Developers. And the thing that I really liked about that exam is there was a little bit that was multiple choice, but most of it was lab. It was, here’s a problem, write some code that fixes this problem, and then that code got reviewed, and that was all part of how you were certified. So if you’re a Chef Certified Developer, it means more than you actually memorized a bunch of answers to a question, but you actually were able to put hands on keyboard and do some things. And I think as that’s something that, um, as technology has advanced, we’re able to test for that a little bit better than we could in the ’90s, right? Right.
Jay: [00:16:52] And the interview has evolved that way too. If you think about it, testing and eventually the interview, it’s no longer like, what do you have on paper? Where did you go to school? Like that, that stuff is less important, I think, to hiring managers now than it ever has been. It’s less where did you go to school or what certs do you have, and now it’s more about let’s see in practice how you would accomplish this task if you were stuck with this particular task.
Matty: And I think that that’s— to kind of go off on a little bit of a tangent about that— a place where, just like you said, how would you go about solving this task? And I think if you’re going to test for that, you need to allow the person to solve it the way that they would solve it, which means that having tests that don’t allow you to use Google, I think are flawed because who remembers every single flag to a command? You know, we all— this is how we develop, right? You have API docs up in one window, you’ve got Google up in another one, you’ve got your text editor over here and your test simulation over there. And I know, for example, when I— it was kind of funny when I interviewed for my current job, they had said— so there was a coding interview. They had said that was gonna be on there and I kind of freaked out because I’m not a big coder, but I was like, okay. But I said, you know what, I’m guessing they’re gonna probably want me to do something against their API. So the day before the interview, I looked up the API and wrote some Go code that just did some funky little stuff because I wanted to kind of understand how to get a token, how to consume it, blah blah blah. And then when I went in for the interview, they gave me the task and I said, wow, I’ve written code that almost does exactly this. Is it okay if I just pull up the stuff I already wrote? And they said, yeah, absolutely, that’s what you would do, right? You have some snippets, you have some stuff. And to me, that was a really great experience because it wasn’t like, no, go, you know, under the gun, blah, blah, blah, because that’s not how we work, right? We don’t work in these clean rooms where you’re not allowed to collaborate or look for, look for more information. So I think that if you want to understand how someone is going to work, you need to replicate the conditions upon where they will work. Right, you know, and we hear about that in whiteboarding interviews a lot too, where that’s not necessarily how someone is going to actually work. And I’ve had— I had interviews years ago that I really loved that were for system engineer jobs and system administrator jobs where I was in a room with 3 people from the team I would be joining and they said, here’s a problem we have, lead us in solving the problem. We are at your disposal, right? So it was, it was an actual collaborative test. And I, you know, was like, well, you guys got some free troubleshooting out of this, I guess, maybe. But to me, that was— and that I really enjoyed that as an experience because it also let me see what it was gonna be like to work with that team. And it was more the way it was going to really work. I wasn’t going to be expected to solve this problem completely by myself.
Jay: [00:19:54] Well, you know, that’s the point, I think, is it makes a lot of sense that if you’re going to enable people to show you how they work, don’t limit them. Give them the tools to go ahead and show you how much they can do. And sometimes that means you need to RTFM, even for, you know, a person who’s been in technology for, you know, 10, 15 years. You’re not going to remember every single little nuance. And I think it’s worth it to remind ourselves that even when we’re looking for the best possible candidate or, you know, we can’t expect people to be you know, memorization tools is the way I look at it. We should expect them to actually like build things, not just repeat information, you know.
Matty: Well, it’s about being able to synthesize information and not just memorize information. And testing for that is harder, right? Because it’s more qualitative than quantitative.
Jay: Sure.
Matty: But that’s how you’re going to get a better understanding of a candidate for, for sure.
Jay: [00:20:57] So anyway, the thing that I really took into it was like the idea of how I decided how I was going to start to learn again, I guess, is what the way I really wanted to think about it is that taking new swipes at continuing to grow as a technologist, it’s always difficult to find the best way to start learning again when you want to take on a few new tasks. And while, you know, always continuous learning, always trying out new things. But, you know, let’s say you want to ramp up for a new specific idea, you know, it might mean taking on a brand new piece of technology and you’re going to actually have to spend time with it. And so I’ve just tried to find new ways to do that. And, you know, I’ve, I thought about how I teach others and I do a lot of like video tutorials and stuff like that. So I decided, you know, start looking for video tutorials, start finding, you know, the stuff that I, I try to make myself when I create. So look for better documentation that people put together, you know, looking into these things and then eventually seeing if I actually do know what it is I’m trying to learn. And I think, like I said, I think I liked using a certificate is, is just a way to kind of remind myself that I can still take a task of a brand new thing, even as a 40-year-old in, in technology. You know, old dogs do tricks, blah blah blah. I think it’s important to constantly just be trying to do some trick, you know what I mean?
Matty: [00:22:32] Yeah. And if— and, and everybody has different, different drivers and different reward systems, and someone like, like yourself and like me, that’s a nice— it’s a nice carrot. Right. It’s a validation. Yeah. Yeah, absolutely. You get your dopamine rush, you get your little certificate, you get your little logo thing that’s— no. And here’s the thing. It’s like nobody may care about it but you, but guess what? That’s totally fine because it’s what matters more is that you care about it than if anybody else cares about it. So if it makes you feel good, then absolutely, then rock it. Right. You know, yeah.
Jay: And I think it’s, it’s just cool that if you start finding these ways to grow as you continue to like age into what roles you are in technology. And I think it’s important to always remember that the tools you use now will probably not be the tools you’re going to use in 5 years or even maybe 2 years. I think it was funny to read Corey Quinn say, you know, well, in 5 years Kubernetes won’t exist anymore, or nobody will care about it. And to a point, he’s probably right. To a point, maybe he’s not. But, you know, because every company still has that one legacy thing that we all thought by now would be gone. The point I’m making is that everything keeps changing, obviously. And that also means the individual, you know, roles that we have and how we prepare for those roles every single day.
Matty: [00:24:02] I’ve told the story before where I had found an old Outlook file from when I was a network engineer in the late ’90s, and I was rereading it. Now, this is about 10 years ago, but I was reading it 10 years later, and I’m reading emails that I wrote, and I’m like, I don’t understand what I’m talking— I sound very smart. I sure seem to know a lot about frame relay. I don’t remember what any of this stuff means anymore, but at one time I had a huge amount of knowledge about this, and it is completely irrelevant to my existence anymore. So it’s been pushed aside with, with new stuff. And, and that’s okay, you know, because otherwise, other than like getting into like a bragging fight on Slashdot about remembering, you know, intricacies of NetGUI, it’s probably not that valuable.
Jay: I mean, it’s like what I try to do on the podcast I do which I’m going to plug right now. It’s called On-Call Nightmares. You can find it on Twitter, @oncallnightmare. Anyhow, is I try to bring up the old days, if you will, with some people who have been in those positions. But what I don’t do is I don’t glorify them because there’s no reason to kind of glorify some of the ways that people had to handle things in technology because For a lot of us, we remember that we went through some really awful times because we allowed certain companies to say, this is the way you work, instead of, these are better ways to work. And so I like to kind of tell the stories without making it feel like there was anything great about it. Like, it’s cool if you can remember a really massive failure on a technology that’s no longer relevant, but I don’t think it makes you better or worse than the next technologist. I just think it gives you different experience and perspective.
Matty: [00:25:53] Yeah, I mean, there’s nothing— there was nothing glamorous about the 2 weeks when I had to walk around a data center logging into thousands of servers, each one in a different domain with a different administrator password, so I could patch SQL Slammer on it. You know, that wasn’t glamorous. That sucked. That was unpleasant. And I don’t even consider that like a battle scar that someone should be— that I should be proud of that happened. I’m I’m glad that we’ve gotten better at stuff like that because that was such a waste of my time. And time is a thing that you can’t get back, right? Like, we can’t manufacture more of that. And I didn’t learn anything from doing it. All I learned is that patching at that time of the industry sucked.
Jay: You know, I like to tell— I have this little story that I remember from years back, and I think I might have told it on my podcast, but I don’t know. But One of my worst on-call moments came when, I guess it was maybe like ’05, ’06, when a data center at a company I worked, the ATS didn’t work. And if you don’t know what an ATS is, it’s an automatic transfer switch. It’s the piece of equipment that literally says the power from the utility company is no longer working. Go to a UPS, then go to a generator immediately. So data centers are built to make sure that this thing fucking works, period. If there’s one thing that needs to work in an entire data center, aside from say like power and air conditioning, you know, all the other stuff would be nice. But to have a data center that people are actually going to feel good about spending money on, making sure that the power, if it goes out, will still work on the generator, it’s just important. So I guess it was a Saturday or a Friday, one of those like in the evening in New Jersey. I’m home. I live maybe about 35 minutes away from this data center, and I get a phone call from a guy I work with, and he says, well, Jay, the power went out because of the storm and the ATS didn’t kick. So every single machine in the data center is off right now. And I’m like, well, that’s like 2,600 servers. And he’s like, well, it’s good you know how to count. And I say, great, thanks a lot, I’m on my way. So I drive like that 25 minutes along Somerset, New Jersey down to the data center. I get there and there’s a bunch of people doing what you do when a data center has no electricity. They got some doors open to cool out the space and just a bunch of people standing outside smoking cigarettes. And it’s the thing that I remember the most is that all we did after that was like we got the power in the building up thanks to like people who got paid more than I did. But then after that, we spent the entire night making sure that machines that didn’t come back online, we figured out why they didn’t come back online. And the ones that didn’t come back online because of kernel failures or, you know, NT errors, whatever it is, or NTBOOT, or whatever that file was that never fucking came up. Um, you know, we spent a whole night repairing those. So you’re talking about, you know, a good 4 to 5 hours of like FSCKing disks, uh, check disks, things like that. And I thought about it, you know, years later, we didn’t learn a damn thing. Like, as technologists, as the people that were actually doing all this stuff, the ops people, the on-call people. None of us learned a thing. The only thing that we learned was that our company had not made the proper decisions to make sure that we didn’t get screwed over. And so, um, I think about those moments and now I think about now. And I think about how much less the data center is not working happens to people. And sure, not, you know, my bank. Apparently they have a problem with that and fire, but It’s just kind of amazing just to think back to where we’ve come. And I guess that’s why I think about learning, to be able to learn from those situations and say, I didn’t learn a damn thing. And then to go now and think about, you know, years later, like web traffic and patterns and stuff like that. What did I learn from that? You know what I mean?
Matty: [00:30:19] I like to think about the wrong things that I learned from outages. And so this will be a little spoiler for when I’m finally on your show, because I’ve realized like the ultimate, call nightmare to share on your story, on your show, but I’m going to tell it now, um, because it will, will play into— because it plays into what you learn. So this was early in my career when I was working for that systems integrator I talked about when I got NT certified. I’d been working there for about 2 weeks, and I lived about 10 minutes away from the office. And so one night, about 9 o’clock at night, my pager goes off and the mail— our mail server is down. And so we were also an ISP. You know, so we did mail for a lot of people. So my pager goes off, says the mail server is down. So I call my boss, who’s also the owner of the company, to basically say, hey, Dan, do you think I should come in and take a look at this? And he goes, no, no, no, I got it, I got it. I’m already in the office, I’ll take care of it. Now, that was the first problem, and there was a lesson that was learned from that, which we’ll talk about in a minute. So fast forward to the next morning, I walk into the office, and, you know, sitting in the bullpen, which is where all of the engineers, you know, the 5 or 6 of us that work there, and the mail server happened to sit in there, is my boss bleary-eyed on the floor with a server completely disassembled, just boards and parts and cables all over the place. And I was like, Dan, what did you do? He goes, well, I was trying to fix it. I was trying to fix it. So I ended up spending hours reassembling this computer, putting it back. It was definitely, it was a software-related issue, had nothing to do with the hardware. And this was because the owner of the company was one, when there’s something wrong, I gotta do, I gotta do, I gotta do, was never thinking about And the lesson that was learned from there was anytime in the future, if I was ever not at the office and I would get paged on something, I would call anybody at the office who would answer the phone and say, keep Dan away from the computer, keep him away from the server. I will be there in 15 minutes. Because it would happen. It was like he felt like he had to do things all the time. And so what did I learn? I learned keep the boss away from things that are broken. So that was what I learned in my informal postmortem.
Jay: [00:32:25] Yeah, it was weird to have a postmortem that literally said, please fix the thing that was broken, or please keep, you know, Joe Blow away from it.
Matty: But sometimes— or when you would have backup plans, it would say turn the server back on. I remember that. I remember having a— we had this old network box that nobody was using. We were pretty sure it hadn’t been accessed in months and months and months, and we’re finally going to be ready to decommission it. So I had to put in a change control request to basically turn off the server. And so I put it in and it gets kicked back to me because I didn’t have a backup plan. And so I’m venting to the person sitting in the cube next to me about like, what am I supposed to do? Just say like, yeah, turn it back on? Well, it turns out that the person on the CCRB who kicked it back to me was hoteling in the cube across from me and said, yes, that’s exactly what you should have done. And I felt embarrassed, but But it’s sort of some of those things where you’re like, literally all I’m doing is turning a thing off. How am I going to back it out? I’m going to turn it back on. That’s a whole other episode, is to talk about CCRBs.
Jay: [00:33:28] I’m sure. Well, I hope, um, I hope I helped people like learn something about learning today, because I, I don’t really know what else I could tell people other than like I’ve come to see that there are some certifications nowadays that I think they’re worth your time. I think it’s worth it for you to consider still for certain particular roles. Like, I still think Amazon certifications are really interesting, that I think that they can help certain people who want to qualify skills do that. But like I said, I don’t really look at them as a a mark for whether or not you’re good at a job. But I think I said, if you’re looking for a way to kind of test whether or not you feel you’re up to snuff on what the vendor is, give it a shot. Take their test if you can, especially if you can afford it. That, that’s a piece of advice I can give. Like, I’m lucky my company will let me take our exams for free. So I’m going to try and do what I can because I know that I’m only going to be better at what I do if I keep learning. And I think that that also comes with like learning about like what you do with Incident Commander and looking at how an incident happens. Like, I’m guessing that, you know, that was a new skill you had to learn, the whole idea behind incident management.
Matty: [00:34:51] Absolutely, because the industry has matured so much since the last time I was on call and the last time I did this kind of work. And so I was not in— I mean, I wish that we did things the smart way back when I had to carry a pager. And but yeah, it was definitely— it’s taken me time to come up to speed and understand and learn, and learning that from internal training and then also train-the-trainer kind of things. You know, as I’ve given the training, I’ve learned about doing it, and I take rotation as an incident commander. I’m carrying a pager again, so to speak, which is kind of freaking me out a little bit. I thought I was done, but you know, it’s kind of exciting. You know, I also— and on that note, so as we wrap up, I believe in the future I’ve been inspired. We will be launching an Arrested DevOps Listener Certification Program where you can be a certified ADO listener. So, uh, you’ll have to know such interesting trivia as, uh, what is Bridget’s preferred airline, um, which, uh, which anime series Trevor, uh, is most fond of, and what microphone Joe recommends to most guests.
Jay: [00:36:01] Bonus points maybe though if you know what meat Pete Cheslock is cooking right now.
Matty: That’s true. That will give you— that could be the plus, the plus Pete. You can be an ADO plus Pete certified. It’s like being plus I. So Jay, thank you for taking time today on this, uh, this Wednesday to, to chat and everything. It was super fun. Everybody make sure you check out Jay’s podcast On Call Nightmares. You can find it at On Call Nightmare on Twitter. And just Google On Call Nightmares podcast. I’m sure you’ll find it, and we’ll put a link to the show notes and all that good stuff.
Jay: @jdestro is, uh, where you’ll find shitposting and other tidbits of technology.
Matty: So please enjoy opinions about the Yankees. Yes, well, and Rico the pug.
Jay: Yeah, my dog’s pretty cool. I was gonna say he’s not in the room today, uh, only because when I do podcasts, he normally snores so loud that he drowns out most of the room.
Matty: That can be a thing. So head over to arresteddevops.com/certifications for this episode’s show notes. Uh, site has 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. And as always, I’m Matty at Matt Stratton. This is Arrested DevOps, and remember, there is always DevOps in the banana stand.
