Screaming in the Cloud - Episode 63: DevOps for Dummies with Emily Freeman

Episode Date: June 5, 2019

About Emily FreemanEmily Freeman grew up in the “swamp” as Trump lovingly refers to it. With politics in her blood, she chased after her dream of living out an episode of the West Wing. After four years of arguing — pretty much sums up a PoliSci degree — she left school disappointed that campaigns are more about recruiting 20-year-olds to live in poverty than it is to wine and dine Koch brothers.Her dreams of Aaron Sorkin-level dialogue and Michelin-star dinners dashed, Emily took up ghostwriting. No, those bloggers you read with millions of followers don’t write their own articles. Sorry to disappoint.After many years of typing, Emily had a slightly-older-than-quarterlife crisis and made the bold (insane?!) choice to switch careers into software engineering. With no experience at all, she packed her six-month-old daughter, blind dog and a few boxes into her anti-mom mobile of a sports car and drove across the country to attend a seven-month code school.Emily completed seven grueling months of code reviews, pair programming and learning Ruby on Rails. After falling in love with Denver, a city as vibrant as she is, Emily decided to stay.Emily is the author of DevOps for Dummies and the curator of JavaScript January — a collection of JavaScript articles which attracts 30,000 visitors in the month of January. To learn more about Emily's story, visit Growth in Fear.Links Referenced: @editingemilyemilyfreeman.io

Hello and welcome to Screaming in the Cloud with your host, cloud economist 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. Logs, logs, logs, logs, logs, full of repetitive noise. Logs, logs, awk and grep, sorry, they're toys. Everyone hates the logs. Nobody reads their logs.

Improve the state of your logs. Scalar can help with your logs. Logs, logs, logs, from Scalar.com. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by your friend and mine, Emily Freeman, who's a senior cloud advocate at Microsoft. Welcome to the show, Emily. Thank you. Thanks for having me.

No, thanks for coming. So you are a cloud advocate at Microsoft, presumably Azure. Yes. And that's a cloud-ish. Hey. So tell me a little bit first about what is it you do as a cloud advocate? So very similar to any kind of developer relations role, as a cloud advocate, I am sitting in that space between the developer communities and the product teams at Azure. And so day to day, it can vary. But generally, I focus on creating high quality technical content that could be writing, speaking, video, but also relaying feedback from those developer communities back to the product teams so that we actually build Azure in a way that solves the problems you're currently having.

I'm having many problems, and I'm not sure how much any one company can do to solve them for me. Most of my problems have long names and are expensive to fix. I feel like that's more like therapist. Exactly. It feels very much like cloud is more about transitioning group therapy into a corporate setting. Yeah, that's not wrong.

You could argue that's what DevOps is too, to some extent. It really is. As of the time of this recording, you have put a nearly final draft of DevOps for Dummies to press. Tell me about that. Yes. So I'm currently in the review. They've already marked it up with plenty of red.

And now I'm kind of going through and making sure that I actually agree with my past self. But it's been an adventure. I wrote the book. It's a high level overview of DevOps as a methodology and how to actually implement it as a practice. So with DevOps for Dummies, I tried to hit all of the sort of stages of DevOps, including the start where like, okay, I've heard of this. What is it? How do I implement it? How do I transform the company and get people on board? I talk a lot about persuasion and, you know, showcasing how DevOps can improve your team's velocity, whether to executives or other engineers, all the way through, you know, injecting DevOps into every piece of the software delivery

lifecycle. So I'll admit, when you first mentioned that you were writing that book, my immediate response was that DevOps is such a broad and vast topic that how could any one person be qualified to write a book on this? And then about a year and a half ago-ish, you wound up giving a keynote at DevOps Days Indianapolis. And it was the first talk, given that it's a keynote. I would say it's almost a value note more than a keynote, but that's okay. And you opened with the line, the dumpster is on fire. And then the fire alarm went off. It is, you could not have timed that better. I don't know who you bribed to pull that off. And that was the single greatest display of DevOps mastery that I've ever seen.

So the question is not who are you to write the book? It's who the hell am I to question you? That's amazing. Yeah, that experience was hilarious. I felt like, okay, I've peaked as a speaker. I will never surpass this moment. I have to stop speaking now. For the record, I did not bribe anyone at the hotel. Oh yeah, you have intermediary cutout to do that for you. I understand. I understand. Possible deniability, Corey. Exactly. So how long did it take you to write the book? So this deadline was insane, in my opinion. I think overall, it took six months to write it and complete it, send it off, which is really fast. Like that's a lot of that's a lot of typing at night, drinking wine in your bed, silently crying to yourself. Write drunk, edit crying.

Yes. There's a whole cycle to it. And it's pretty similar intense in a book, because I think it is so final, right? Like, I am canonizing my thoughts on DevOps into a book that I cannot change in the future unless I earn a second edition. And that's very scary that I have to like really nail it so that, you know, the little mistakes don't follow me for the next five years. Here's the $64,000 question.

Would you do it again? So good question. I'm of two minds about this. The instinctual response is like, hell no, I'm never doing this again. That was such a, it was such a crazy experience. Um, and so draining. I mean, emotionally, it's just incredibly draining. Um, and energetically like just empty. But that was my first book. And Oren, my colleague, actually brought up the fact that the first book is your hardest because you don't actually know that you can finish a book, right? You approach the project, you're like, I think I can write a book, but you don't know that you can actually complete such a Herculean task.

And once I've finished it now, I feel almost like I've finished the training course on writing books, and I feel like the subsequent books would go more smoothly for me. But I also feel like this is that sort of like post, you know, childbirth high where you're just like, that wasn't so bad. And that's when the acquisition editors pounce and get you to agree to a second one. A hundred percent. Yes. So I'm definitely in that sort of blissful. Yeah. I kind of like this, this moment. so let's say that i get a wild idea that today i'm going to sit down and pitch a book and it gets accepted now not by the dummies books or any of the other publishers you've heard of because they all have editorial standards and well have you met

me so i'm going to self-publish a book or get someone doesn't know what they're getting into to agree to green light cloud for morons. And I'm going to go ahead and write that book. What should I know going into it? Okay. What should you know going into a book? One, I think it's really important to have a unique point of view. Uh, and that can be your past experience. It can be a strong opinion for how you think the industry should continue to evolve. But it needs to be a strong point of view in that you are uniquely telling a topic in your specific story format, right? Like you are forming your story from your point of view. The second thing is that I think you have to understand just how much energy it's going to

take. And with no like emotional feedbacks or little wins, right? There's no like, when you write a blog post, you write it, people read it, people respond. This is even a faster cycle with social media. So if I tweet something that a hundred people like it, I feel good, right? Like there's like that little dopamine drop. It's very short cycle time. Exactly. The book, the book takes, it's a marathon. It's an absolute marathon. And, you know, for someone like me, who's, who's very much more a sprinter, um, both psychologically and physically, it was a real challenge to just kind of keep pushing through. It sounds like the exact sort of thing that I would sign up for naively and then immediately regret that decision and spend the next 18 months sobbing.

Yes. No, there's, there's a lot of, there's a lot of crying. Um, the other thing, uh, my editor had this great, uh, line when I, when I turned in my last chapter and I was like, it's done. Uh, he was like, congratulations on completing what more accomplished people than you could not. And I was like, damn, yeah, a lot. That's very heavy. And it made me feel good. I was like, yeah, yeah, I finished a book. I wrote a thing. But yeah, I think a lot of people sign up for a book and then figure out that they're either not the right person to write the book or they need a co-author or they just simply can't do it.

For me, it always seems that it would be a terrible idea not because I know what it takes, I don't. I sometimes lose interest halfway through writing a tweet but I talk to people who've written a book uh you mike julian who's my business partner and a few other people and whenever i say should i write a book immediately they get a look in their eyes that can only be described as haunted and don't don't write a book is usually what they say like the same tone of a four-year-old girl out of nowhere who appears to you at an airport when you're boarding,

who just looks at you with this thousand yard stare and says, don't get on the plane. You're like, I'm going to die. I'm definitely going to die. Exactly. I'm training my daughter to do that incidentally so that I get to clear the upgrade list faster. So I get the upgrade every time rather than just sometimes.

Let's talk about the substance of what you wrote, not the ins and outs necessarily of what you wrote, because I don't think you want to continue talking about that given you're about to go on a book tour of some sort. If not, surprise, you're going on a book tour. But the bigger question I have is, is DevOps still relevant in this year of our Lord 2019? Yeah, this is a debate I think is starting to surface. And I think a lot of people have different opinions. Mine is that it is still very much relevant, but the sort of adoption cycle has shifted. So the adoption curve,

we're further down on the adoption curve. I think when you and I talk about it, or people like Jason Hand, Chris Short, when we talk about DevOps, we've been in it for a really long time. Many of us have actually been involved in DevOps for a decade. And so we've seen how it kind of, in our experience and talking to people,

and specifically on that sort of cutting edge of technology with startups and such, we see it sort of tapering off. We see the holes in DevOps and how it needs to evolve into something else. And I think part of the answer for that is SRE, site reliability engineering. But that is a little bit more prescriptive and there's some polishing that I think needs to be done around that. But that said, I still think that DevOps is incredibly relevant for people and companies and engineering teams that are just a little bit later to adopt it, right? Like we take DevOps for granted,

but for many people, DevOps is still a very new concept. It's still something that they're not super familiar with, and they certainly don't know where to start as far as implementing it. Is it just a CICD practice? Like what exactly is it? And so for me writing this book, I wrote this for a CIO in Hartford, Connecticut for an insurance company, someone who has to think about security and compliance, someone who can't move as quickly or take on the latest and greatest technology without first vetting it. And so this is the person I had in mind writing this book for. That is absolutely a valid approach. And don't let my snark in any way detract from the value first of what you've done. And secondly, from the value of transitioning your culture at an organization into something. That second one was to the general you, not you personally. Yeah,

I'm not terribly worried about people worrying that I'm being too snarky or sarcastic to Microsoft's internal culture. I think you've got that. It's been 40 years. You're a trillion dollar company. You got it. This is more for folks who are still finding their way. Yeah. Yeah, absolutely. And I think we're all sort of finding our way in different paths, right? So one of the things I talk about a lot in the book is I don't want DevOps to be this, you know, sort of sexy thing because I don't think that really answers the question. When you or I get up on stage and we talk about a greenfield environment and, you know, it's all unicorn and sunshine and DevOps is the solution to everything, I think that's bullshit. And it cheats the actual methodology of stretching and

beginning to solve problems in the nitty gritty, in the legacy systems that have existed for 15 years, where, you know, there's that one piece of code that no one touches because it works and no one knows how it works. And obviously when we can't mess with it at all. And I think a lot of code bases, probably the majority have those sorts of problems and tendencies. I've never met a code base that isn't a complete shit show that's longer, you know, older than like two weeks. And so.

No, no. Even when writing things in the middle of it, it's a Lambda function. It's four lines and I'm on line two and I'm looking at this going, this is a tire fire. And I know it going into it. That doesn't make it better, but at least I'm not blind.

Yeah, there you go. There you go. Yeah, so I think it addresses some of those nitty gritty problems. And it kind of gets into the more difficult challenges, which I think are more interesting and fun to solve. One of the challenges now is that you see that the term has almost been co-opted by people who are driving transformational change and grifters. And it's sometimes challenging to figure out what's what. You see a bunch of sysadmin teams that are just rebranded as DevOps, which, if that's you, frankly, good for you.

Because we did a survey a few years back. I think it was DevOps Days Austin, but don't quote me on that. And it turns out that with DevOps in your job title, even though the job is functionally the same, it winds up being something like a 30% pay bump. So yeah, if you want to call me something that pays 30% more, I don't really care what that is for the most part. I'd prefer nothing scatological, but I'm willing to flex if you can go to 40%. I like that.

I like that resume-driven development. Oh, absolutely. Where do you think Kubernetes came from? But now we're starting to see this branch out into other things with DevSecOps and FinOps. And I'm sure people put QA into it, but there's no way to get that without coughing up half a lung midway through the word. Coops is not really a thing. And at some point, it starts to take on a parody of itself element, where it's no longer about having these different cross-functional teams collaborating and communicating in a way that makes sense for everyone, so much as it is talk to other teams and do your job. And that seems to get lost somewhere along the way in a profound

way. It feels that by slapping a new shiny DevOps-ish label on something, that is going to magically fix all the broken processes and lack of cultural advancement going on in any given company. And you're not going to fix anything, but you're going to feel better for doing it. Yeah, I mean, absolutely. I think you bring up quite a few of the problems that I have with, you know, the current sort of status of DevOps in the industry. I think it's suffering from a lot of the same issues that Agile has and is suffering from, which isn't surprising, right? DevOps was born out of Agile. And because it is such a, it's not a prescription, right? There's no like do this, this, and this, and then you'll be fine.

It's more, you know, yeah, work together, assholes. Do your job. Talk. Communicate. If you're a manager, be a good one. Protect your engineers, uh, give solid market, um, salaries, incentivize the team in the same direction. So they're not fighting each other.

Um, these all seem like very basic principles of just good business, but the truth is, and this goes back to my power lifting days when When I was lifting, some of the best advice I ever got was, you know, it's very easy to do the complicated thing. You know, if you're doing like a let's take diets, a complicated diet is in some ways so much more easy to actually go through with and to experience because you have like your exact prescription for what to eat and what not to eat or you're just on like a seven-day fast or something. It's much harder to do the simple thing and I think

DevOps is the embodiment of doing the difficult simple thing. The actual principles of DevOps are pretty simple and straightforward. But implementing them, it takes a lot of energy and a lot of collaboration. And those things, like the human problems, the human problems of tech are the most complicated, in my opinion. Oh, absolutely. And I'm reminded of all the early days of DevOps in the serverless environment that we're seeing today. I keep hearing echoes of a blog post as it lurks around the internet,

and I'll throw a link to this in the show notes, called DevOps is a Poorly Executed Scam. It's from March of 2011. So it's by a guy named Ted Zubia, and his entire approach was that it felt like the second coming of Agile, but there wasn't going, but no one was asking for money. There was no conference. There was no books. There was no training.

You've gotten a bunch of buzz, but no one's selling anything to you in this space. Well, in the DevOps world, I think we've fixed that. And it just took a little longer than people expected it to. But now I'm starting to see some of the same hype style stuff with serverless, where people are going significantly out of their ways to build things that turn into a somewhat insane and ridiculous approach, where everyone's trying to build things in Byzantine ways is the best expression of ideological purity. And often they blame each other for not wishing hard enough to build the thing and being traitors to the cause. And it just winds up being something awful and unsightly. I don't think that we're quite there

yet, but I'm starting to worry that that's where we're headed. Yeah, No, I think that's fair. It's funny you say at the beginning DevOps didn't have a ton of vendors trying to sell things. I am actually coming to the perspective that engineers as a whole are not extrinsically motivated with money. I think we all want to be paid fairly and we all want to be able to support our families and do things, you know, that we care to do.

But that aside, like throwing extra money at an engineer doesn't typically get you a ton of long-term motivation. Repeating that again will get you a bunch of highly motivated engineers to silence you who want large piles of money thrown at them. That's fair. That's fair. Yes. But that said, I think...

Hey, any large piles of money probably won't solve your problem, but let's try it. Yeah. Yeah, exactly. What was that study like a couple of years ago? They found that after like $75,000 or something, extra money doesn't bring you any of their happiness or something like that true that is normalized as a baseline load it tends to vary based upon major metro areas obviously but you're right past a certain point you aren't going to be measurably happier with two yachts instead of just one yes exactly though that second yacht i mean oh my god You're truly wealthy when you can walk in

and pronounce it phonetically as yachts and no one corrects you when you're making the purchase. God, that would be special. I would like to see that. Can we do that and like record? I feel like that would go viral, Corey. This is the entire problem is that whenever you and I hang out,

it immediately leads to hilarious and disastrous encounters for everyone around us. We were at Build somewhat recently, and we happened to show up at the same off-book meetup near the same time. And you walk over, and Corey, you start seeing the new pin on my lapel and start fidgeting with it. And someone just asked, do you know him? And the obvious immediate response was, no, why? Yeah, it went super well. And everyone just sort of looks at us and stares.

And we're terrible influences on one another, which tells me we absolutely need to collaborate more and inflict this on the world somehow. Yes. I think both of us are very comfortable in awkward social situations. And then it becomes compounded when we're together. And then we kind of, like, I get joy out of making things a little weird. I just think it's funny.

Oh, if we're not in an awkward situation, we make it that way. That's who we are as people. That is fundamentally our nature. Yes. Which I think a lot of people just looking at me don't think about. They don't see the sort of mischievous side, but it's definitely there. Oh, absolutely. It's one of those things where it's the kindred

spirit approach where it's, we're effectively, we see the world in the same bizarre way. One of these days we have to find some kind of collaboration opportunity. I don't know if that's you give a talk or something, and then I give the rebuttal to that talk or picture like the political state of the union things. We have the opposition party go up and do a well actually afterwards, only that with more swearing and screaming. Yes, but we should do it in like a British parliamentary way, like where we can kind of just yell at each other. Oh, absolutely. And go round and round and round and round and forget a deadline's approaching and then continually push it back, which is, I'm told, how you write a book.

I want to come back to that. But I do, I wanted to do, like, I had an idea for a conference where it's basically debates for charity. And so you get people, like, I want two people that sign the Agile Manifesto, like Kent Beck and someone else, to debate whether they think it still holds or something like that. And then we pay to attend and donate all the money to charity. I think that'd be fun. I love that entire idea. I think that's something that is phenomenal. I'm always a big believer as well in doing things like that for charity, because let's not kid

ourselves. No one is going to pay money to me to watch my ridiculous horseshit. But they might tolerate my ridiculous horseshit if it benefits a good cause. Definitely. And I think a lot of us struggle with, okay, you know, many developers and engineers didn't come from well-off families. A lot of times, you know, especially with code schools, you see someone being the first person in their family to make, you know, X amount or six figures or be able to support their family and bring them out of poverty. And so I think a lot of us struggle with, okay, we're here, we make a really solid wage. How do we make sure that we're giving back and we're not just, you know, living in a sort of self-centered and selfish way that we actually embed altruism into our

everyday lives? That's something I struggle with. Like, I don't always know the answer to that. So yeah, I think there's a lot of opportunities for charity in this industry. Absolutely. And there's a reason that every year I do the charity t-shirt where it's something snarky and sarcastic for last week in AWS and all proceeds go to a random charity. Last year was, who was it? A St. Jude's Medical Center for kids with cancer research. That was fun.

I don't know who it's going to be this year, but I have some ideas. But doing something like that that's larger than just my own ridiculous nonsense slash corner of the internet is, first, it feels good. And secondly, it helps justify, if only to myself, that I can take this ridiculous love affair I have

with my own personality slash sound of my own voice and use that as a force for good beyond just insulting things all day long. I think that's wonderful. Yes, yes. Insult for good beyond just insulting things all day long. I think that's wonderful. Yes. Yes. Insult for good. I want to loop back to the procrastination in writing because this was fascinating to me. If I had to write a book on writing a book, it would be lessons I learned from staring at carpet fibers. And it's because you struggle.

Like you sit there, you stare at the computer, the blank page, the Word document, because I had to type in Word. Feel sorry for me. And then you're like, ugh. You go through this phase where you're like, I'm not the right person to do this. I have nothing to say on this.

I'm the worst writer in the world. And then you like roll around on the carpet a few times. If you have a partner, you know, you'll talk to the partner like, I shouldn't be the one writing this. This isn't right. And if you have a crappy partner, they come back with, you're absolutely right. You're good at nothing. Yeah. Don't stay in those relationships, please. Get out. Yes. Talk to me. I will help you. Exactly. It's a DevOps metaphor. There you go. So, yeah.

And then you kind of roll around and after five hours of moaning, you pull your shit together and then you type some words. And about three pages in, you're like, oh, my God, this could be a book on and of itself. And so it's a fascinating sort of process. And procrastination, I think, actually plays an important role in that you're not actually just sitting there moaning. I mean, that's sort of the output. But I think the process of that and the journey of procrastination is you're truly ruminating on what you're going to say. And it doesn't feel productive, but I think your brain actually needs that time to sort of sort through random thoughts before it can be coherent and clear written. This aligns very heavily with a pair of conflicting Twitter takes I saw going around a few months ago, where on the one hand it was, well, we just paid a lot of money

for this conference, so thanks for telling us you threw the talk together that we're paying to see the night before. Awesome. Thanks. And the counterpoint to that is, sure, they finalized their slides the night before. But they've been thinking about this talk for months and months and months and months and months. And then finally had a forcing function of building slides. Because you're not paying for the slides. You're paying for the viewpoint, the perspective, the story that goes along with it. So I'm extremely sympathetic to both sides of that.

Yeah, and I think, you know, it's funny, this is apt timing. I had a nightmare last night that I haven't, I'm keynoting DevOps Day Serrano in like two weeks and I haven't actually started the talk. And I know what I want to say, but I had a dream that I didn't finish the deck and I had to talk with just like a six

slide deck and it was bad that said we will not let that sneaky way around that incidentally is to give a talk with no slides if you bring in there are a couple devices to do this and talk to me after the show i'll give you links for these that you can plug into a projector and it turns the thing into a paperweight because it lets the magic smoke out of the back oh no the projector exploded i guess i won't do my slides and i'll just do it without slides then all you into a paperweight because it lets the magic smoke out of the back. Oh no, the projector exploded. I guess I won't do my slides and I'll just do it without slides. Then all you have to build is a title slide. Fascinating. Okay. Yeah. That's one approach. The way of the weasel. That's not my approach. We've talked about this. Well, yes, because you're good at things and I'm

just really, really, really good at distraction. Well, and you're so comfortable sort of riffing on stage, whereas my personality doesn't work like that. Like I'm contextually funny, but I'm not, you know, like you could be a stand-up comedian. I wouldn't be a good stand-up comedian. What do you mean could be? I go to Seattle once every month or so and do Tonight in AWS. I make fun of cloud computing for 40 minutes.

It goes super well for all proceeds to charity. There you go. And most of us just, we don't have the skillset or confidence to do that. The only skillset I'm convinced that you need is a complete lack of self-awareness and or shame. And as long as you've got that, everything's great. Like the crowd boos, they pull you off the stage.

And then people ask you that, how'd it go? It killed. Everyone was cracking up because you, you're always a legend in your own mind. It's true. It's true. Um, and related to that, I think writing a book is interesting. When, when you said you were asking your friends, like, what should I write a book? I think one of the interesting byproducts of writing a book is the credit that other people give you for free, right? Like I'm more or less the same level of intelligent and, you know, filled with the same level of knowledge that I was six months ago. Now I just wrote it in a book. But when you're an author, people give you a lot of credit. They're like, well, you must know what you're talking about. You're an expert.

Really? What book did you write on that? Because I wrote a book. That's exactly it. And so it's this sort of ace card or this trump card you can kind of hold if you need it. Yeah, it's definitely one of those appeal to authority things. And there's also, not for nothing, but again, I have written no book

of any stripe, color, et cetera. I mean, at this point, I might be able to write a matchbook and that's as far as it goes. But it also has its own gravitas when you're with a known publisher as well. I mean, the Four Dummies series was transformative. This dates me, not like anyone else will.

But back in the 90s, I got started with Linux for dummies. That was my first outing to the idea of a Unix-like operating system, and it was captivating. I love that. Yeah, I'm excited about the dummies, and I think it doesn't get the credit that it deserves in that it fills a piece of the market where you can be a complete beginner. You don't actually even have to know much about tech to read my book. Like you can glean a bunch of things about management in there, about being a leader without a management title, about, you know, energizing and galvanizing your team, no matter what your job is. And so I really tried to write it and meet people where they were at to make sure that, you know, it would be applicable to them,

no matter where they are along the process, what their background is, what they look like, where they came from, how they got into tech. I didn't want any of that to matter. I wanted it to be completely open and to answer the questions that anyone coming to it would have. And I think that's absolutely the sort of thing that is important for people to hear. We've been joking a bit and snarking at one another as we do. It is our way. But there's extreme value in making things like DevOps and modern technological practices and culture shifts accessible and approachable to people on a wide variety of spots on the spectrum. And I don't want our sarcasm and joviality to wind up occluding that.

Yes, absolutely. And I think tech in general could do better at this, I think, because we are such an intelligence-focused industry where we measure ourselves and each other based on what we know. It's very difficult for us as engineers to say, I don't know that, or I've never heard of that, or explain that to me. Or to mistake things that are common in the industry as prerequisites. Well, I don't think I'd be very good at doing DevOps style work because I'm not very good at coming up with puns. Wait, what? Yes. Yeah. No, absolutely. We think that you need to have, you know, X factor on your resume to do whatever else. And I think that's

bullshit. And something I've been focusing on at Microsoft is, you know, I as usually stands for infrastructure as a service, and I apply it as idiot as a service. So I am open to looking like a moron and asking the dumb questions so that everyone's on the same page. Because if you don't have that foundation of clear communication and context and understanding why you're working toward a goal, the whole thing's going to fall apart at some point. It's a house of cards. And something I'm trying to focus more on is giving more airtime to my stupid questions. Most of the time, it turns out it wasn't a stupid question at all. There's something there that I'm not getting

and I need to understand. That's the point of asking a question. But it's easy to lose sight of it when people aren't doing that in the open, where they realize they spent three hours messing around with something and realized that they missed a comma or they're using the wrong version of a thing

and the documentation says in giant bold red letters, do this thing first. And if you don't do that, surprise, it doesn't work. And everyone has those experiences of going back and forth rapidly, cycling between I am a genius and how am I allowed outside unsupervised? It's back and forth so quickly.

I know, I talk about this in my Dr. Seuss talk, where there's this rhythm to software development. And it's like, oh, this should be easy. No problem. You dig into it a little bit. And then you're like, eh, that doesn't seem so easy or straightforward. And then you're like, help. I need help. I have no idea how to do this. I'm an idiot. And then when you actually solve the problem, either individually or as a sort of team, you feel like a god, like a god of all things machine, you know?

So if people want to hear more of your sage thoughts slash scintillating wit, where can they find you? Yes, so you can pre-order DevOps for Dummies on Amazon. You can find me on Twitter at EditingEmily. EditingEmily was my writing business before I moved into tech. And you can watch my talks at emilyfreeman.io. And we will put links to all of those in the show notes.

Emily, thank you so much for taking the time to have a chat with me today. I appreciate it. Thank you. I love talking to you. Emily Freeman, Senior Cloud Advocate at Microsoft, of which Azure is a cloud. I'm Corey Quinn. This is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold. This has been a HumblePod production. Stay humble.