Screaming in the Cloud - A Non-Traditional Path into the SRE Folds with Serena Tiede

Episode Date: August 10, 2021

About Serena Serena Tiede is a SRE at Optum, a healthcare technology company that manages everything from the delivery of care to the management of patient data. Prior to becoming an SRE they were a Kafka operator for real time security logging and ingestion. In their off time, they moonlight as the proud admin of an incredibly over engineered Minecraft server.  Links:Optim: https://www.optum.com/Twitter: https://twitter.com/SerenaTiedePersonal Blog: https://blog.serenacodes.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Your company might be stuck in the middle of a DevOps evolution without even realizing it.

Lucky you. Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy-in on DevOps practices? Well, download the 2021 State of DevOps Report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping mid-evolution firms

stuck in the middle of their DevOps evolution because they fail to evolve or die like dinosaurs. The significance of organizational buy-in, and oh, it is significant indeed, and why team identities and interaction models matter. Not to mention whether the use of automation and cloud translate to DevOps success. All that and more awaits you. Visit www.puppet.com to download your copy of the report now. This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me.

I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing, in various parts of your environment, wherever you want to. It gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of. Canary.tools.

You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets NMAP scanned or someone attempts to log into it or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is

enterprising. Take a look. I'm a big fan of this. More from them in the coming weeks. Welcome to Screaming in the Cloud. I'm Corey Quinn. A recurring theme of this show has been for a while, where does the next generation of cloud engineer come from? Because the path I walked of being a grumpy Unix admin isn't really as commonly available as it once was, and honestly, I wouldn't wish my path on anyone in good conscience. My guest today is Serena Tidi, who's a site reliability engineer at Optum and didn't start their career as a grumpy systems administrator. Serena, welcome to the show.

Hey, thanks for having me. I'm so pumped to be here. Don't worry, it will soon pass. What I'm wondering is you didn't come to be an SRE through a giant ops background of clawing your way up by dealing with hardware and data centers and driving it on safe speeds in the middle of the night because someone tripped over a patch cable in the data center. You have a combination of traditional slash non-traditional background. Tell me about that. Yeah, so it's funny you mentioned hardware. So I went to school for electrical engineering, went to the University of Minnesota because you want to do engineering, you're pretty much going to one of the big state schools in the Midwest. So I grew up and was like, I want to be a hardware designer. I'm terrible at it. So terrible. Wait, I didn't realize that you could want to be things you were

bad at. If someone had told me that early on in my career, it's huh, this might have taken a very different turn and a far more productive one. I just assumed I wasn't good at something. I should give up and never try it again. Oh, I took the courses and was like, whoa, this circuit design, not for me. Then I ended up just taking a bunch of engineering math courses. So I took communications, the digital signal processing controls, and started programming. I was like, all right, let's do embedded systems. No one was hiring. And then come internship time, there's this little company that I've never heard of called Optum. And they're like, we want software engineers. Well, I can write C.

Does that count? Oh, question, of course, to really ask is, oh, can you really write C? Having gone through it, the more I talk to people who've been writing C for their entire career, and you ask them, can you write C? The answer is not really slash reliably. I can basically type, and sometimes it works. And oh, thank God, they're mortal too, was my response. Oh, my opinion. No one should learn C unless there are specific reasons why.

And those reasons are, you're doing embedded systems where I had to learn how to write an assembly. And for three weeks, and then my professor at the end said, hey, we're writing C. Be thankful. It's a high-level language. That is terrifying. But let's get back to this idea of you going to school for electrical engineering. And you didn't just dabble in it. You you going to school for electrical engineering. And you didn't just dabble in it. You graduated with a degree in electrical engineering, didn't you?

Oh, yes, I did. I graduated. It was fun, even though, unfortunately, it still had my dead name on the diploma. So I refer to that as my Matrix Mr. Smith moment. They won't go back and edit and reissue it under your actual name? I haven't bothered to look, but I almost consider it just kind of hilarious and just keeping it that way. No, again, I am not one to

ever advise people how to deal with names. When I changed my name back in 2010 or so, I wound up getting a whole lot of strange looks over it. And it's, honestly, it is no one's business except how you interact with a name, not the direction that we need to go in on this. I'm more interested in understanding on some level how you got a degree as an electrical engineer and then immediately landed a job writing software.

That one feels a little strange. Can you talk me through it? Oh, yeah. So pretty much I took a bunch of operating systems classes and was like, wow, this computer science thing is cool. But I was too far in the electrical engineering track to want to change degrees. So I got the degree, ended up working at Optum. I originally started off in security, oddly enough, for my internship, then came back, did a, you know, we have a rotational program. So I did security for six months, and then wound up on this team for my second rotation where their literal job description, write RESTful APIs and streaming applications. So it wasn't even a software job that focused on the close to the hardware stuff,

where you're doing embedded systems. That would at least make a bit more intuitive sense to the way I see the world. No, this was full-on up-the-stack REST API stuff. Oh yeah, I tried embedded, but in my market it was all medical devices. And between all of us listening here i don't do well with medicine get very squicked out very faint so decided all right let's go up the stack and turns out it's like okay kafka streams and then we were trying to figure out okay why are our services like how do we know if it's saturated i'm like oh well we have this Prometheus thing. This sounds cool. And it was deployed on a rudimentary Kubernetes cluster.

Oh, hey, there's this cool service discovery thing. Let's do that. And then one thing led to another. Thanos was coming out. And before it had a release candidate, I decided my claim to fame at the company was like all right let's do this that i was saying because it seems really cool i read about it on reddit and the distinguished engineer in the room was like oh yeah i heard about it on hacker news do it i did it was rough but it was so cool and then i come back like a year later because i

went back to security for a wee bit, and the same monitoring stack is still there. And they're like, hey, can you do more monitoring things and pivot to observability? Yeah, let's skip past the obvious joke that I could make about someone at a healthcare company saying, let's do it, because I read about it last night on Hacker News, because it's just too easy at some point. It's odd, though, because I always about it last night on Hacker News because it's just too easy at some point. It's odd though, because I always held the belief somewhat publicly that an SRE role was not going to be a junior role. It was something that required quasi-significant experience to wind up moving into it. It's always felt like a transition from traditional ops roles or folks

who are deep in the weeds that have been doing software engineering at scale to a point where they see how these systems fail over time in production scenarios, it doesn't sound like that was your path at all. Not to delegitimize your path by any stretch of the imagination. This is more to do with me reevaluating how I view SRE as a field that people get into and how they approach it. I just fell into it. And the reason why I bring up my digital signal processing background is a lot of the SRE stuff, I look at all of our time series metrics, and it's like, oh, well, this is just a real-time stream of data that we scrape periodically. And it's like, oh, cool. So we can look at our averages, percentiles. I can eventually do some really cool fancy digital filtering. And kind of was like,

oh, wow. I kind of know the math behind a lot of this stuff and just have to just brute force apply it in places. Tell me a little bit more about that, because with my approach to SRE, which let's be clear, was fairly crap. The math that I tended to do was mostly addition and subtraction. And for the really deep stuff, I used the most common tool to manage anything at scale, Microsoft Excel. And that mostly handled even the addition and subtraction for me. What math? So for me, a lot of it comes down to, I actually have my signals book in the other room. The big concept behind all these systems is the concept of sampling. You're not going to real time get memory and CPU data every second. Processors are running at gigahertz of speed.

You would need double that to recreate your signal with full fidelity. That's the Nyquist sampling theorem. But you kind of can fudge the numbers a little bit and just say, do we need that granular of detail? We're not trying to reproduce what happened in the past, we're just trying to see what's going on now. So I say, okay, 15 second scrape interval, things are looking good. And then rolling into what I'm doing later of applying like, all right, let's do some fun control loops because people wanted service level objectives. People want service level objectives. Everyone loves them some SLOs and SLAs. No one wants to figure out by hand what their baseline is.

But, again, some fancy, this is more controls math, figure out what your baseline is just automatically. And do some little magic in the frequency domain, courtesy of Laplace transforms, and that's it. I can just

automate that for you and remove the human from the equation. I'm still somewhat astounded by the fact that people calculate these things out mathematically instead of, you know, dead reckoning and confident-sounding estimation. It's really just bringing that electrical controls background to software.

Honestly, I'm kind of baffled that no one else has found this hack because i'm just thinking oh well i can't be that unique like someone else has to have done that and then it's i talk to the people in the room and it's like oh wait no i am the only person here so that's my whole thing everything is just applied math and all of our human debt reckoning. It's great, but it doesn't scale well. My boss wanted me to figure out how to do our SLOs for the entire team. And turns out, when it came time to hire, realistically cloning myself was not an option. For better or worse, it seems like it isn't. So what was your first exposure to the SRE-style space? You started off in security, but looking at the timelines on this, it wasn't

that long ago. It feels like you were probably not exposed, in many cases, to physical data centers as much as you would be cloud, or at least not having to image bare metal systems. Were you up at the AMI level, or was it beyond that and having virtual machines that moved around into full-on containers or serverless? So I started my internship in 2016, got my full-time offer in 2017, and we started having our container platform start becoming this up-and-coming thing. You know, my lead engineers were like, all right,'re going to have to learn this thing called Docker. And I have never heard of it, but I was just amazed at, wow, I can just run these little itty bitty pods anywhere on this hardware. And later on, I did do some virtual machine stuff,

but I've had the luxury of all of this years of pain and toil to be able to say, oh yeah, I can just manage things with Ansible, create my Docker files and do everything from a code deploy pipeline style. And it was awesome. And I just can't fathom what it's like to work without those tools. But knowing the past, it's kind of like, wow, we have gotten a lot farther.

Things are abstracted. This is actually kind of nice. It kind of is on some level. I feel like my initial reticence towards containers, I gave a talk, Heresy in the Church of Docker, which sort of put me on the speaker map once upon a time. And it was about all the things that Docker as a technology didn't really have good answers for. Honestly, the reason that I gave the talk was I assumed that it did have answers and I was just unaware of them. And I just gave the talk so I could publicly become the idiot who didn't know what they were talking about and then get well actually to death by ducks

slash Googlers. And it turns out that no, no no at that point in time these things were not well understood or solved for the observability stories the metrics the logging the orchestration the security story the how you handle things like state etc etc etc and kubernetes these days has largely solved a lot of those problems but i don't dabble in those spaces just because I'm outright ornery. Back then, it was a weird problem, but these problems have largely gotten solved in some ways. But I sort of just skipped over the whole Kubernetes slash container renaissance, and personally, I went directly into the serverless world. What's your take on that? Oh, so as someone who loved Kubernetes, I was a serverless skeptic initially. I was like, well, I can just build my Docker file and write the deployment manifest. No big deal. And then I started working on my side project. For, I think, better purposes, my cloud account is tied to my credit card, and I have to actually be on the hook for cloud bills.

And I use GCP for my home lab, and lo and behold, one million requests a month for free. And I love the sound of free when it's my money on the line. Oh, yeah. Company money versus enterprise money, radically different scales. I mean, if you try and sell me personally a $50 hamburger, I'm going to tell you to go to hell. If you try to sell me as a representative of my company, a $50 hamburger, I'm going to need a receipt. Exactly. And then also like I'm just running through, I was redoing one of my serverless functions and watching the deploy steps. And then one of my coworkers introduced me. He's like, Hey, Serena, you heard this thing called BuildPack?

I'm like, no, what on earth is that thing? And he's like, oh, well, you take your code, and then it just magically turns into a container. I'm like, bull crap, show me. And lo and behold, code goes in one end, nice little container comes out the other. And that crap was magic. It really does change the world if you let it, I think. I know it sounds like a ridiculous, I guess, hype-driven thing to say,

but for the right use case, it's great because it removes the entire administrative burden from running services. Now, critics are going to say that, well, that means you're just putting all of your reliability in the hands of your cloud provider. Yeah, we're kind of all doing that already. Serverless just sort of forces us to be a little bit more honest with ourselves about that. Oh, yeah. I mean, even if you self-host things, like you are relying on, you know, your data center ops people to like make sure, oh, I don't know, your machines don't literally catch fire.

We literally had a bug one time where it's like, why is this one node bad? Oh, actually, hey, did you increase the fan speed? Someone had to literally go increase the fan speed for one of our servers, which, again, in the serverless and cloud provider world, I don't think about that. The cloud is just infinite to me. It's just computers and APIs as far as the eye can see. It's wonderful. It really is. It's amazing, and it's high level,

and on some level, you went from getting a degree that required you to write assembly and super low-level stuff and figure out how hardware works into, let's be honest, writing in your primary language, which for all of us in SRE land is, of course, YAML. Ooh, I am a very spicy YAML engineer. YAML and a little bit of Go for when I need to make things go. You ever notice there's never a language called stay or stop or anything like that? It's always about moving to the next thing.

And in engineering, we always have sprint after sprint after sprint, never a, it's a marathon, not a sprint. Relax, walk, enjoy the journey. Nope, nope, nope. Faster, further, sooner. Yeah, it is honestly weird because my relatively short career span, you know, it's 2021 and I graduate in 2017. The company is like, hey, you're a senior software engineer now. Here's a program. Here's a budget. Go forth. Oh, that's lucky.

It must have been amazing to have an actual budget when I started out. I was in one of those shops where it's, yeah, Palo Alto wants $4,000 for that appliance. That's okay. We have some crappy instances in PFS sense, and we could wind up spending eight weeks of your time to build something not as good. Get on it. Well, the hilarious part is I'm stressing out about every single dollar I'm spending, and then my boss is like, oh, you know your budget is super small potatoes, right? Compared to our other stuff? Don't sweat it. It's fine.

I keep making this point to the cloud providers where their somewhat parsimonious free tiers are damaging longer-term adoption because I look at building something myself in my spare time in my dorm room or whatnot, and I'm spinning up some instances that talk to each other, and I want to use a load balancer, and I want to use a managed NAT gateway, God forbid, and at the end of the month, I get a bill for $300 and it's, what the hell is this? I thought I was on the free tier and it scares the living hell out of us. So we learn not to. And, oh, don't use that thing. It's expensive. And you'll inadvertently spend 80 times as much in what your employer is paying for your time rather than using the high-level thing because they could not care less about a $500 a month charge.

And it's this weird thing that really serves as a drag on adoption. It's super weird i actually literally had this conversation with one of my engineers who wanted to hey we're trying to expose a grpc thing and i had issues getting it to work with an ingress and he's like do you want me to take a crack at that and i'm like look at the price of the load balancer and i'm like unless you can figure it out in half an hour it is literally more expensive for you to continue tilting at that windmill than for us to just leave it be and it's also weird i have my personal stuff where i'm trying to keep my cloud bill to you know maybe a humble 100 a month max versus, oh, the enterprise? Oh, yeah.

That's just logging that you're paying for, which is baffling to me. I feel like as engineers, we always, always, always fall into this trap. And maybe I fall into it worse than others because my entire business is actually lowering the bill. But when I started as an independent consultant, my bill was something like seven bucks a month, which, yeah, I'm pretty content with that. And I started looking at ways to gulf it lower, which in most cases is never worth the time. But in my case, I should really understand every penny of the AWS bill or I'm going to have a problem someday. And now I look at it recently because we have a number of engineers building things here and our bill was

over $2,000 a month. And true story, by the way, it turns out that your AWS bill is not so much a function of how many customers you have, it's how many engineers you have. And I look at this and, oh my God, we need to fix that immediately. And I spent a little bit of time on it and knocked $500 off, and whew, that's better. And it still bugs me to see a $1,500 bill. It feels like it's an awful lot of money. I mean, think of what you can buy for 1,500 bucks a month. And then in the context of the larger business picture compared to payroll, compared to all the other nonsense we use like Tableau, for example, it's nothing. It is a rounding error that gets lost in the weeds. I never understood that before having access to company budgets. When I was an employee, this was never explained to me.

So I was always optimizing for absolutely the wrong thing in hindsight. It feels like this is part of the problem that we run into as a culture when we don't give our staff context to make the right decisions. Yeah, I actually do appreciate the way my company does things because I am like, not personally my bank account, but I am like responsible if someone should ask, hey, what's this charge for? I have to say, oh, well, it's for all of these things and we need that. But for the most part, it's been really weird to kind of learn like one of the ways I kind of sped up my like, okay, I need to learn how business works. What do I do? Well, quite honestly, a lot of my cloud cost tips I have learned from your various podcasts.

Oh, that's a problem no but like all of a sudden like all this stuff and just hanging out on tech twitter and hearing all the advice of people and then it was kind of a weird way of like yeah years wise yeah some people might look at me askance and be like you're really a senior engineer but then they hear me speak and it's all about like, oh, well, again, I stand on the shoulders of giants, which is awesome. And I'm honestly just hoping that one day I will write something that is very cool and then someone will say,

oh, well, they were right on these things, but not right on this. Let's edit this to make it a little bit better. And the standing on the shoulders of giants trend continues. This episode is sponsored in part by Cribble Logstream. Cribble Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere to anywhere. Simple, right? As a nice bonus, it helps you not only improve visibility into what the hell's going on, but also helps you save money almost by accident.

Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell into a company name. To learn more, visit Cribble.io. That's C-R-I-B-L dot I-O. And tell them Corey sent you, and wait for the wince. I'm a little taken aback by the fact that you've learned a lot of this stuff from the podcast because I tend to envision when I'm telling stories about this, companies that show ads or my mythical Twitter for pets startup. I have to remember that there are banks, like is one of the examples of serious businesses that I use all the time, but you're in healthcare. I'm sorry. That's more serious than finance. Just because,

I hate to say this because it sounds incredibly privileged and I don't even care. It's only money. What is money compared to the worth of someone's life? I don't think that you could ever draw an equivalence and I feel dirty every time I try. When you're working with things that impact people's ability to access healthcare, that is more important than showing banner ads. And a lot of the stories I tell about maybe it's okay to have downtime. Yeah, because yeah, if AWS takes a region down issue for an afternoon and you can't show ads to people or your website isn't working, yeah, that's kind of sad. And it's obviously not great for your business. But at the same time, the stories in the news are always about Amazon's

issue, not about your specific issue. If you're in an environment where there's a possibility that people will die if what you have built is not available, we're having a radically different conversation. Exactly. Fortunately for me, I personally, not working in the kind of care delivery space, but the stuff I'm working on right now is supporting that lovely end of the year where it's open enrollment, all the employers are saying,

hey, time to re-up your benefits. Yeah, it's kind of a big deal that our site doesn't go down because... Yeah. And open enrollment, to my understanding, changes based upon what plan you're on. I've known companies that have open enrollment in the summertime. I believe ours winds up coinciding

pretty closely with the calendar year, but I've certainly worked in environments where that wasn't true. So being able to say, oh, it's fine, it's April, no one's doing open enrollment now. Is it actually true? So it totally depends on which part of your business. If you're going through the healthcare exchanges, that's usually more in the fall. I think the Medicare plans, those are a little bit before the individual enrollments.

And there's a ton of these things that, even though I just work tangentially, that I'm just not even in the know for. And then, of course, we talk about open enrollment. But the thing that a lot of people don't really talk about is, so what happens when your plan goes live on January 1st of the next year? Yep, our site's still got to be up. And it's a responsibility I take really seriously, because it impacts so many people.

It really does, and it shouldn't, to be clear. I try to avoid getting overly political on this podcast, but the state of healthcare in the United States, as of the time of this recording, is barbaric. And I really, really, really hope there comes a day where someone's listening to this and laughing because it's such an antiquated and outmoded story that isn't true anymore. But I'm terrified that it won't be. And yeah, having access to a website lets you sign up for healthcare during a limited period of availability. If you miss that

window, you don't have healthcare in many cases until the following year when open enrollment opens again. Or, honestly, you wind up changing jobs because that is a qualifying event to change healthcare. Well, I missed the open enrollment window, so I have to quit and take a job somewhere else is a terrifying thing. It's bad for the business for a variety of reasons, but that pales in comparison to the fact that people have to make life-altering career decisions based upon a benefit that is routed through an employer when it should not be. Okay, I'll climb off my soapbox.

Oh, it's bizarre to me. Honestly, for better or worse, I argue worse, but I'm honestly optimistic. One of the weirdest things I saw that stuck out from the most recent stimulus bill was, oh, hey, we're having a special enrollment period during a pandemic. I'm like, you know, it's not 100%. Maybe we should just extend it to the whole year, but

it's better than what was the previous state. I can't make even in my work life, I can't make everything perfect. I can't make, I mean, even in my like work life, I can't make everything perfect. I can't make outages go to way, but I can make things just a touch better. And that's, that's all I can do. Sometimes all we can do. And I wish there were better ways to handle that. I don't know what the future is going to hold, but I also think that there are bright areas. There are aspects that are promising as far as the future being brighter than today. The overall trend, I hope, is for humanity to uplift itself.

Totally. Again, I do want to highlight that you went in a very strange direction where you went from software engineering, a generally pleasant job, to SRE, which is horrible and would not be recommended to anyone. What guidance would you have for people who are, for some godforsaken reason, trying to figure out what their career trajectory is going to be like and thinking that they might want to become an SRE, even if they're not in tech yet? Because for some reason, they hear the stories and think there's some nobility and suffering or whatnot. Well, for starters, for me, it kind of came down to get real good with discrete math. It's boring, but that's kind of the bread and butter of the concepts I've learned. Also, for junior people, like if you're also just curious, say you've written an app, go over to OpenTelemetry.

Go like instrument your stuff and see how many requests you get in a day. Start getting your hands dirty with instrumentation. Look at how cool it is. And then maybe you want to start structuring your logs. Maybe you start end up doing tracing. But at the end of the day, it's all, for me, I think best learning is just experiential. And one of the things where, how do you learn from production outages? Go to happy hour with some of the senior people and listen to the stories that they tell. With enough

time, they become funny, but they're also valuable learning things. The aspect I would push back on is the hard requirement around discrete math. I don't deny that it has been helpful for what you've done and how you do it. I don't know how any of that stuff works. On paper, I have an eighth grade education. That was never my path and never my strong suit. I would agree that knowing it

would have made aspects of what I do easier, but the bulk of it, I don't necessarily know that I would agree. I guess my counterpoint slash pushback would be that if you thought you liked this, but you don't want to deal with the math, it's not a hard requirement. And I don't think that I would frame it as one. Actually, that is a very good catch. Like, it is not a hired requirement. I am not sitting here in my notebook scribbling away at equations. But

the concepts that I've learned from a while back, it's the concepts are way more important than the actual computation itself. Because computers do that. And a computer will absolutely run circles around me. Most of us do. Unless, you know, the computer is an overheating processor from Intel.

But that's a little bit of a low blow. Not that it stopped me, but it was a low blow. Well, I mean, your local science supply shop might have some liquid nitrogen. Maybe. So what's next for you? You started off in security slash software engineering, transitioned on over to SRE work. What's the next step? What's the beyond for you? Ooh, great question. So I don't really know. I'm enjoying the SRE thing at some point, might write a book trying to make all the concepts I've learned from my electrical engineering degree maybe a bit more accessible. Be it a series of blog posts, maybe a book. I would love to get a book published.

And honestly, just writing more. Because knowledge should be shared. And if someone learns something from my nonsense experiments on my home lab, then cool, it's all worth it. I'd agree with that. I'm a big fan of learning in public. One of the, I guess, magical things that I do, for lack of a better term,

is that I will stumble my way through learning a new concept that I have no idea what I'm doing. And when I get lost, I call it out because invariably I'm not the only person who runs into that problem. But for folks who don't have, I don't know if it's the platform, the seniority, the perceived gravitas, the very intentional misdirection where I fooled the entire world with thinking I know what the hell I'm doing, whatever that is, most people have a problem with admitting they don't know something and learning in public. So anytime I can take up that mantle or that burden, I love doing it just because I don't

have any technical credibility to lose from my point of view. I wish that that were more accepted and more common. That's why I'm so intentional about being able to talk on some level about the things I don't understand or I know that I know nothing. And I just run with that. Because I, I mean, even though fortunately for me, my corner of the internet, as like, a non binary person, no one's really mean to me when I say, okay, I broke my DNS. Because honestly, I knew DNS conceptually when I was setting up my Minecraft server for friends. But I never really got it until I, well, kind of broke it. And eventually fixed it. But I hope that over time it becomes more acceptable to say, I don't know things.

Within my team, I tell anyone that's working with me when they're asking me a question, say, I don't know. But I have a feeling this rabbit hole this trail of crumbs might lead us to an answer and then it's a fun little adventure i miss the days when i could describe what i do as a fun little adventure it's now oh dear lord it's this bullshit again uh this that was my sign that was i was burned out in time to find other things to do than keeping sites up. Now I have no on-call responsibilities because there's no real site to keep up. Thank you, serverless. I get to sleep at night again. But there are times I miss aspects of working in

the trenches, of being able to dive deep into a problem on a very large-scale architecture. The grass is always greener somehow. The grass is always greener somehow the grass is always greener in a weird way i actually i complain about my on-call weeks but i actually kind of love them there's like a weird camaraderie about all of us dealing with this shared thing and on my team it's really cool because we do this whole thing where you know i have these junior people asking oh am, am I going to go on call? And we're like, well, unfortunately, you're not quite fully baked yet. Not quite ready. Once you're here longer with us, then, yeah, we'll go walk you through a game day and make sure you can do all the things.

But being on call, it should not be like a punishment for people. It's honestly, it's just the greatest feedback mechanism that guides me because I say, wow, this stinks. This could be better. And then try to make it better. If people want to learn more about what you're up to, how you think about these things, or potentially even reach out for advice, where can they find you? So I am on Twitter at Serena, S-E-R-E-N-A, T-I-E-D-E. DMs are open, come bug me. I got my lovely blog.

It's just blog.serenacodes.com. It's pretty bare bones, but I'll have some new content up there, hopefully pretty soon, once I get around to writing it. And say hi! I like meeting new people. And learning new things. Adventures await. And we will of course put a link to that in the show notes.

Thank you so much for taking the time to speak with me. I really appreciate it, Serena. Hey, thank you. I am so happy to be here. This was like one of my life goals, and now I don't know what to do now that I've gotten out here. That's the problem. Achieving this bucket list items is, oh, well, I wake up the following day. Now what do I do? And my life eventually returns to normal on some level. Thanks so much for your time. I really appreciate it.

Thank you. Have a great day. Serena Teedy, site reliability engineer at Optum. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment saying that if you think that C is a high-level language, oh, just wait until you explore the beauty and majesty of Rust. If your AWS bill keeps rising and your blood pressure is doing the same,

then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.